Repository navigation
feat(cloud): Stream all container logs to Telegram in realtime - #142
Merged
Merged
Conversation
- Add Telegram streaming functions with batch buffering (5s interval) - Replace Claude Code launch with streaming pipe for all output - Stream self-review steps (format check, generated files, diff size) - Stream push and PR creation steps - Add TELEGRAM_STREAM=true env var to cloud_orchestrator Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Mar 18, 2026
…ic Demo API 100/100, Community Testing 60/60, Release Validation 50/50 (210 queries 100%) [Golden Chain #142] 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Mar 18, 2026
feat(cloud): Stream all container logs to Telegram in realtime
gHashTag
added a commit
that referenced
this pull request
Aug 14, 2026
Adds "Six and a Half Years in One Discarded Return Value", on the four nextpnr-xilinx fixes that turned the openXC7 demo-projects CI green (#142, #144, #145, #146). Claims are anchored rather than estimated. The six-and-a-half-year figure comes from git blame of the placer1_refine call site (1b587cb5, David Shah, 2020-02-13), not from the file's creation date -- that file has 59 commits, half of them from this summer. #134 is described as still open, because the merged #146 code still produces a bitstream that is non-functional on silicon. Enabling the blog needs the preset block plus blog/authors.yml for the authors key the post references. The site builds clean both with and without the post. The .gitignore change is load-bearing: a global `*.md` rule matched the post, and `!docs/` re-includes only the directory, not markdown inside it, so the file was silently left unstaged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Aug 14, 2026
The previous commit said the file-reading and subprocess paths could not be
compiled locally. That was true of the toolchain then present; it is no longer
true. Zig 0.15.2 (the version CI pins) now builds the whole module here, which
took one non-obvious step worth recording: on this host the macOS 26 SDK is not
understood by 0.15.2's linker, and `-target aarch64-macos.13.0-none` is what
gets it to link libSystem.
Building an executable rather than only running `zig test` is what mattered.
Tests reference the pure scanners, so lazy analysis never compiled the rest --
the same reason the first version of this file passed 5/5 while `readPosts` did
not compile at all. An exe forces the whole call graph.
Running it then found a real defect that no amount of reading would have:
`actualState` duplicated the trimmed gh output and never freed the original, so
every receipt checked leaked its stdout buffer. GeneralPurposeAllocator's leak
detector named the address. Replaced with a defer.
Verified end to end against production data:
blog list -> 9 posts, 0 drafts, all bilingual
blog check -> 5 receipts on the new post, all agreeing with the GitHub API
(#142/#144/#145/#146 MERGED, #134 OPEN), 0 leaks
blog live -> resolves index-*.js then Blog-*.js on the apex and finds the
slug; a slug that is not published exits NotLive with the
explanation rather than an error
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Aug 14, 2026
Citing a comment in a post is normal — the href is .../pull/142#issuecomment-5268596254 — and the ref parser took the whole tail as the number, so the lookup would have 404'd on a perfectly valid reference. It surfaced as `check` reporting "state not named" for two receipts whose labels did in fact name one. Found by using the tool on real content rather than by reading it, which is the second defect this file has given up that way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Aug 14, 2026
The previous commit said the file-reading and subprocess paths could not be
compiled locally. That was true of the toolchain then present; it is no longer
true. Zig 0.15.2 (the version CI pins) now builds the whole module here, which
took one non-obvious step worth recording: on this host the macOS 26 SDK is not
understood by 0.15.2's linker, and `-target aarch64-macos.13.0-none` is what
gets it to link libSystem.
Building an executable rather than only running `zig test` is what mattered.
Tests reference the pure scanners, so lazy analysis never compiled the rest --
the same reason the first version of this file passed 5/5 while `readPosts` did
not compile at all. An exe forces the whole call graph.
Running it then found a real defect that no amount of reading would have:
`actualState` duplicated the trimmed gh output and never freed the original, so
every receipt checked leaked its stdout buffer. GeneralPurposeAllocator's leak
detector named the address. Replaced with a defer.
Verified end to end against production data:
blog list -> 9 posts, 0 drafts, all bilingual
blog check -> 5 receipts on the new post, all agreeing with the GitHub API
(#142/#144/#145/#146 MERGED, #134 OPEN), 0 leaks
blog live -> resolves index-*.js then Blog-*.js on the apex and finds the
slug; a slug that is not published exits NotLive with the
explanation rather than an error
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
gHashTag
added a commit
that referenced
this pull request
Aug 14, 2026
Citing a comment in a post is normal — the href is .../pull/142#issuecomment-5268596254 — and the ref parser took the whole tail as the number, so the lookup would have 404'd on a perfectly valid reference. It surfaced as `check` reporting "state not named" for two receipts whose labels did in fact name one. Found by using the tool on real content rather than by reading it, which is the second defect this file has given up that way. Co-Authored-By: Claude Opus 5 <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
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.
Closes #131
Changes
Rate limiting
Telegram limits private chats to 20 msgs/min. With batch every 5s, max is 12 msgs/min per container. 3 concurrent containers = 36 msgs/min — safe.
Verification
After deploy, every agent run should produce Telegram messages every ~5 seconds.
Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com