Keep substreams run stdout to module data only - #884
Merged
Conversation
Human-readable status lines were interleaved with the JSON module data on standard output, so piping the output into `jq` broke on the first non-JSON line. The most visible one was the `Completed successfully` trailer. Route all informational and diagnostic output to standard error: - `Completed successfully` and the `received <signal>` shutdown notice - the `cursor` and `clock` output-mode banners, which polluted the very streams those modes exist to produce - the `Error wrapping message` diagnostic from the JSON formatter - the `.substreams.env` loader messages, which fire on every invocation when the file exists # Conflicts: # docs/release-notes/change-log.md
maoueh
force-pushed
the
feature/substreams-run-stdout-spurious-printing
branch
from
August 17, 2026 20:11
5316c9a to
be66d09
Compare
Contributor
🔍 Vulnerabilities of
|
| digest | sha256:a9cf33e1748e97c6103fb006e30e11b789ff6c84d71b09ad7f6df8103c804b90 |
| vulnerabilities |     |
| platform | linux/amd64 |
| size | 123 MB |
| packages | 382 |
📦 Base Image oisupport/staging-amd64:24.04
| also known as |
|
| digest | sha256:019e8eb29a85e74d64925745884f2ec79aa27e3feab36353d24656f4d6b89467 |
| vulnerabilities |   |
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
3 participants
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.
substreams runmixed human-readable status lines into standard output, so piping its JSON intojqor any other consumer broke on the first non-JSON line. The most visible one was theCompleted successfullytrailer printed after the last block.All informational and diagnostic output from the run path now goes to standard error, leaving standard output carrying nothing but module data:
Completed successfullyand thereceived <signal>notice on shutdown.cursorandclockoutput-mode banners, which polluted the very streams those modes exist to produce.Error wrapping messagediagnostic emitted while formatting JSON output..substreams.envloader messages (Reading SUBSTREAMS_API_TOKEN from ...and its read errors), which fire on every invocation when the file exists.The
.substreams.envmessages live in the sharedsinkpackage, so this also affects the sink CLIs that load auth the same way — stderr is the correct stream for them too.Scripts that grep stdout for
Completed successfullyto detect success will stop matching; they should check the exit code, or read stderr.Verified: an invocation in a directory holding a
.substreams.envnow produces an empty stdout, with the auth line on stderr. TheCompleted successfullypath itself was not exercised end-to-end — that needs a live endpoint and an API token, which this environment does not have.