Repository navigation
Scrub uploader email after delivery - #20
Merged
Merged
Conversation
parseMultipartUpload awaits mkdir before entering the promise executor that captures its start time and creates the watchdog interval, and advanceTimersByTimeAsync does not wait for filesystem I/O — so a test that advanced fake time straight after calling it could run its whole trickle loop while that mkdir was still pending, leaving the interval installed after the last advancement with nothing left to move the clock and the rejection pending forever. All three streaming tests now wait on a fileBegin barrier first, which formidable can only report from inside form.parse and therefore proves the interval is live and the start time is pinned to fake-time zero; raising the Vitest timeout would not have helped, since the interval needs time advanced rather than more real time waited. The steady-upload test needed a second barrier: it asserts that neither bound fires, which is the one assertion that depends on the byte counter keeping pace with the clock, and it had only been passing because the watchdog installed too late to evaluate the rate floor at all. It now pushes its payload and confirms the request buffer has drained before letting time cross the grace period, stepping the clock in small increments because Node pumps stream reads through setImmediate, which the fake timers replace. Measured under CPU saturation over 40 runs: the original failed 5 times in 30, the barrier alone moved the failure to the steady test at 10 in 40, and this version failed 0 in 40.
…n comment pumpUntilConsumed could throw after its final advancement even when that step drained the buffer. It now checks readableLength once more before failing. The fileBegin comment claimed formidable reports the event when it starts writing the file. It actually fires once the part headers are parsed, immediately before file.open(). The extra body byte stays: measured under CPU saturation, removing it made the steady-upload drain overrun its step budget in 6 of 38 runs, against zero in 55 runs with it kept.
formidable emits fileBegin immediately before opening the file, not after, so the reported temp path can refer to a file that does not exist on disk yet.
Cry0nicS
force-pushed
the
scrub-uploader-email-after-delivery
branch
from
August 3, 2026 20:00
44bbedb to
76b6907
Compare
Cry0nicS
enabled auto-merge (rebase)
August 3, 2026 20:01
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.
No description provided.