Repository navigation
docs: improve GitHub CLI navigation and linking notice - #260
Merged
Merged
Conversation
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_a4abccfd-83db-4f34-a642-46075cfa2c8e) |
cpojer
pushed a commit
that referenced
this pull request
Sep 11, 2026
#260) * feat(dispatch): explain a worker-timeout 503 in the project log stream A user worker cut at the dispatch budget never returns, so it logs nothing, and `void project logs` was empty for exactly the failure that most needs explaining. The worker does emit a tail event, but its outcome is `canceled`, which a real client hang-up produces too (6,892 `canceled` rows in 2 days against ~1,700 dispatch 503s), so it cannot be used as the signal. Dispatch is the only party that knows it was the one that hung up. On the three worker-timeout paths, `recordPlatformLog` now writes one row into the `void_logs` dataset through a new `LOGS` binding. The row uses the same seven-blob/two-double shape `packages/tail` writes, so the read path in `GET /projects/:id/logs` needs no change and the row already satisfies `--level error` on both the SQL predicate and the CLI pass. Attribution splits `RoutingEntry.workerName` (`user-<slug>-dpl_<id>`) into `index1` and `blob7` exactly as the tail worker does. It deliberately does not reuse the metering `slug`, which falls back to the hostname on a custom domain and would write a key the read path cannot select. A test asserts the split against the tail implementation itself rather than trusting a keep-in-sync comment. The write is best effort and swallows its own failures: every call site is already returning a 503, and a throw there would surface as a 500. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016uLggtyRPe6MYH737LXA1V * fix(dispatch): bound the platform log row inside the Analytics Engine blob cap Review flagged the log fields as unbounded. The stated limit was wrong (there is no 1,024-byte per-blob limit; AE caps the SUM of a data point's blobs, raised from 5 KB to 16 KB in June 2025 - `void_logs` holds rows of 13,695 bytes today, which proves the higher cap is live). The conclusion still holds, and the exposure is measurable rather than theoretical: the longest URL already recorded in `void_logs` is 6,703 bytes against a p99 of 195, and this row carried it TWICE - raw in blob4, and as the pathname inside the blob2 message. A data point over the cap is dropped, and `recordPlatformLog` swallows failures by design, so an oversized row would silently lose the explanation this feature exists to write. `truncateUtf8` bounds the URL at 2048 bytes and the message pathname at 1024, holding any blob set under ~3.5 KB regardless of input. The budget is counted in UTF-8 bytes, not UTF-16 code units, and the cut lands on a character boundary - a split sequence decodes to U+FFFD, which is itself 3 bytes and would push the field back over budget. `index1` is deliberately left whole. It is the read key, so a truncated one would produce a row `GET /projects/:id/logs` can never select, which is worse than a dropped row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016uLggtyRPe6MYH737LXA1V --------- Co-authored-by: Claude Opus 5 (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
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.
Summary
void github linkhandles identities already linked to Void accountsTesting
vp run --filter ./docs buildvp lintvia the pre-commit hookvp fmt --no-error-on-unmatched-patternvia the pre-commit hookKnown limitation
vp run checkis blocked by missing generatedplayground/markdown-blog/.void/tsconfig.jsonandvoid/envtypes in this checkoutNote
Low Risk
Documentation and VitePress nav only; no runtime or CLI behavior changes.
Overview
CLI reference navigation now includes
void githubin the VitePress sidebar so the GitHub command group is reachable alongside other CLI sections.The
void github linksection drops the one-line “different Void account” note in favor of a warning callout. It states that Void accounts cannot be merged, documents refusal when the authorized GitHub user is already tied to another Void account (including GitHub sign-in), when the current Void account is already linked to a different GitHub identity, and that re-authorizing the same linked GitHub account succeeds with “GitHub account already linked.” It also tells users tovoid auth logoutand sign into the existing account or pick another GitHub account.Reviewed by Cursor Bugbot for commit 5409e39. Bugbot is set up for automated code reviews on this repo. Configure here.