Skip to content

Fix range mismatch handling error while patch tracing

Tomasz Maczukin requested to merge fix/trace-patch-missmatch-handling into master

What does this MR do?

This MR adds some tests for trace patching and fix a bug that finishes with a panic while handling a range mismatch in some situations.

Why was this MR needed?

We've had a situation where the same build was triggered second time by GItLab. In GitLab the build trace was 17041 bytes long while the repeated build trace was only 66 bytes long. We've had a RangeMismatch response, so the offset was updated (to 17041) and client.PatchTrace was repeated, at it was planned. Unfortunately the tracePatch struct was not resistant to a situation when the offset is set to a value bigger than trace's length. This MR fixes such situation, adds a test to guard us from regressions and adds some other tests for trace patching feature.

Are there points in the code the reviewer needs to double check?

Does this MR meet the acceptance criteria?

  • CHANGELOG entry added
  • Documentation created/updated
  • Tests
    • Added for this feature/bug
    • All builds are passing
  • Branch has no merge conflicts with master (if you do - rebase it please)

What are the relevant issue numbers?

/cc @ayufan

Merge request reports