Clock-sync both sides of fetchHandler so handlerMs is real - #1676
Merged
Conversation
A handler that performs no I/O leaves Date.now() pinned, so the first run reported handlerMs 0 against 6002ms wall. Sync before and after.
Contributor
Cloudflare previewTorn down — the PR is closed. |
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
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.
First run of the cold/warm probe returned
handlerMs: 0on requests with 6002ms wall time — the sameDate.now()pinning trap: a handler that performs no I/O leaves the clock frozen, so the delta reads 0 for work that took seconds.Syncing with
scheduler.wait(0)on both sides makeshandlerMsa real duration, which finally splits the invocation cleanly into time inside Start versus time outside it.It also already established that
wasWarmis false on every request (13 cold, 0 warm), confirming every Start-handled request is the first in its isolate.