Investigate 416 build trace overwriting mechanism
Description
We are working on Live Trace feature, and we noticed that we might mishandle a case when a partial trace could not be written correctly. We currently only allow appending a trace when partial trace offset equals current size. This might not be resilient to failure enough.
We also do raise a few exceptions that we might want to catch, otherwise GitLab Runner will receive 500 Error instead of HTTP status 416.
Discussion
The following discussion from !37075 (merged) should be addressed:
-
@grzesiek started a discussion: (+6 comments) It is interesting that we are currently not depending on
append_data
orset_data
methods to return a bytesize of data written to Redis. Runner will respond with 416 iftrace.append
returns an invalid value, but instead of returning an invalid value we simply return 500 error at the moment, because we do not catch all theArgumentErrors
we raise in multiple places🤔