Let a deployment raise the digest walk budget - #652
Merged
Conversation
The bound was tunable at construction time and nothing passed it, so the 60 s default governed every deployment with no way to change it short of editing code. The adapter's own comment says operators tune it for long-tail files; they could not. 60 s never fits a tomography scan. Measured on the 2-BM pilot, `sha256sum` alone takes 82 s on a 24.5 GB file, 77 s of that CPU, and CORA's chunked read is slower again. The first real ingest refused with `walk exceeded max_walk_seconds=60.0`. The refusal behaved correctly and is worth recording as a good outcome: zero events across all three streams, the record untouched, and the idempotency key holding the error so a blind retry could not half-ingest. The bound is doing its job, which is to stop a file on a hung mount from occupying a worker forever. It is not a performance knob, and this does not raise the default: a deployment holding files of that size chooses a number that bounds a hang without forbidding its own data. Both construction sites take it, since verifying a 24.5 GB file has the same problem as computing over one. The HTTP range adapter keeps its own default: same shape, but no deployment has met the limit there and no measurement to set it from. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Coverage report
Click to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||||||||||||||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found by the first real ingest attempt at 2-BM, which refused with
walk exceeded max_walk_seconds=60.0.The bound was tunable at construction time and nothing passed it, so the 60 s default governed every deployment with no way to change it short of editing code. The adapter's own comment says operators tune it for long-tail files; they could not.
60 s never fits a tomography scan. Measured on the pilot:
sha256sumalone takes 82 s on a 24.5 GB file (77 s of it CPU), and CORA's chunked read is slower again.The refusal was correct, and that is worth stating
Zero events across all three streams, the record untouched, and the idempotency key held the error so a blind retry could not half-ingest. The bound is doing exactly its job, which is to stop a file on a hung mount from occupying a worker forever.
So this does not raise the default. It makes the bound reachable from configuration, and a deployment holding files of that size picks a number that bounds a hang without forbidding its own data.
Both construction sites take it, since verifying a 24.5 GB file has the same problem as computing over one. The HTTP range adapter keeps its own default: same shape, but no deployment has met the limit there and there is no measurement to set it from.
🤖 Generated with Claude Code