Explore the new handleRuntimeStdio
to ingest workerd logs
#2574
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.
Related: cloudflare/workers-sdk#4357
Context: when we implemented the MiniOxygen version that wraps workerd, the latter didn't support log streaming. We had to add some custom code to get logs from workerd's V8 Inspector (like a debugger behind the scenes) via WebSocket events (e.g. we get a "console.log called" event, then we manually call console.log in Node). This is similar to what Wrangler was doing at the time.
Since that initial implementation, workerd has added log streaming and Miniflare now provides a
handleRuntimeStdio
option where we can ingest logs. This PR tried to simplify our story around logs to use this new utility, and it's relatively similar in feature parity at this point with main branch.However, after testing it in this PR, I've found that it doesn't reduce much of the complexity. Therefore, I'm leaving this PR here for the future reference but won't merge it. Some of the issues with the new log ingestion strategy:
console.log
might be ingested as a single log and is hard to split later. We currently rely on structured logs so that we can enhance them in the CLI (e.g. show banners, dedup certain warnings, enhance GraphQL errors with links to GraphiQL, etc.):console.warn
andconsole.error
are mixed intostderr
and is not possible to tell them apart (we rely on this for similar reasons to2
).One of the things I tried to do to workaround
2
and3
is adding an extra parameter to everyconsole.log
call so it's later possible to know the log order and the console method used. It works in this PR, but adds more complexity because we need to inject code in-worker to wrapconsole
methods.