Gracefully handle more errors during file copy

[MrSerth]

If something goes wrong while copying files, we just want to retry with a new runner. If the error is not expected (which would be only an Runner::Error::RunnerNotFound), we log the error to Sentry.

This PR is related to openHPI/poseidon#649.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.40%. Comparing base (bebfa9d) to head (da4bc97).
Report is 6 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2511      +/-   ##
==========================================
+ Coverage   69.37%   69.40%   +0.03%     
==========================================
  Files         199      199              
  Lines        6347     6348       +1     
==========================================
+ Hits         4403     4406       +3     
+ Misses       1944     1942       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mpass99]

Looks good 👍

However, we should be aware that if someone would be able to find a file copy payload returning an Internal Server Error, they could trigger an infinite loop by CodeOcean always retrying.
On a quick check, I haven't found such payload for users. Teachers, however, are able to do so.

[MrSerth]

However, we should be aware that if someone would be able to find a file copy payload returning an Internal Server Error, they could trigger an infinite loop by CodeOcean always retrying.

I am not aware of this possibility. In the code, we retry exactly once. If the second attempt fails as well, the resulting exception is not caught and further bubbled up, where it will be handled by the corresponding controller and simply return an error.

Teachers, however, are able to do so.

🤔 Are they? Feel free to share more details with me (also via email or Slack)...

[mpass99]

In the code, we retry exactly once. If the second attempt fails as well, the resulting exception is not caught and further bubbled up, where it will be handled by the corresponding controller and simply return an error.

I see, thanks for clarifying this mechanism.

Are they?

They are able to create an Internal Server Error, however, I have not checked the Ruby part that this would actually lead to an Infinite loop (which as you described, does not).