feat: advance the clock by a timer's full duration when passed#77
Merged
Conversation
Passing a `Tn` now advances the virtual clock by `n` frames (its duration) rather than the 1-frame-per-character default. This lets a pull-based consumer drive timing just by iterating — it never has to await `TimelineTimer.promise`, which on a virtual clock would deadlock (nothing advances the clock while you're blocked awaiting it). Add an end-to-end test proving a timeline and a `setInterval`-based transformer (sampleTime) can share one fake-timers-backed clock and line up deterministically, plus a negative case showing the timing barrier catches a value that arrives too early. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.
Follow-up to the virtual-clock work released in 5.0.0.
Why
Consuming a timeline on a virtual clock needs timers to spend their time as they're passed. Previously
onPassadvanced the clock by the token's character count (T40→ 3 frames), and the only way to realise the 40-frame duration was toawait TimelineTimer.promise. On a virtual clock that deadlocks: the promise resolves when the clock advances, but nothing advances it while you're blocked awaiting it.What
TimelineItemTimer.onPass()now advances the clock by the timer's full duration (T40→ 40 frames). A pull-based consumer drives timing just by iterating — it never awaits the timer promise.test/streamBridge.test.ts: an end-to-end proof that a timeline and asetInterval-based transformer (sampleTime) share one@sinonjs/fake-timers-backedClockableand line up deterministically (1 @20, 1 @40, 2 @60), plus a negative test showing the timing barrier rejects a value that arrives too early.Notes
This is the linchpin for porting
@johngw/stream-testto the virtual clock. With it, the consumer fixes are small:fromTimelinedropsawait timer.promise(just moves on), andexpectTimelinereads the shared clock through a no-op-advanceview and yields with a microtask instead of a (fakeable)setTimeout.Behavioural change to
onPasstiming; safe within the 5.x line as timers are meant to represent durations.🤖 Generated with Claude Code