[Brooooooklyn]

Why

A user got a "5xx errors detected" alert for their project but void project logs --filter error showed nothing. Two CLI gaps contributed:

1. --level error never looked at HTTP status, so a worker that returns a 500 without throwing or calling console.error was invisible to it.
2. There was no way to see 5xx that the edge router generates itself (missing manifest, static-asset / SSR timeouts) or requests to static/SPA projects — those never invoke a worker, so they produce no log rows at all.

What

• --level error now also matches a 5xx status. The client-side filter in logs.ts keeps any entry with status >= 500, mirroring the server-side blob6 LIKE '5%' predicate (paired platform PR). A returned-500 with no throw/log is now findable.
• New void project requests command — a request-level traffic view (time, method, status, type, timing) backed by edge request metering:

  void project requests [--status <5xx|500|…>] [--range <duration>]
  

  Unlike project logs (user-worker tail rows only), it surfaces edge-generated 5xx and static/SPA requests that never run a worker. --status accepts a class (5xx) or an exact code (500). Depends on the GET /projects/:id/requests endpoint in the platform PR.
• Wiring: client.getRequests, project-args/project-cmd, help, interactive hint, MCP tool catalog, and docs/reference/cli.md.

Known limitation (documented in --help and the docs): edge metering does not record the request path, so this view shows status/type rather than URLs. Use project logs for per-URL detail on requests that reach the worker.

Tests

• logs-filter.test.ts: --level error keeps a silent-500 (outcome ok, no logs/exceptions, status 500), drops a silent-404; getRequests builds the right query string (omits status by default / for all, appends a class filter).
• project-args.test.ts: requests parsing — defaults, --status/--range, accepts classes + exact codes + all, rejects invalid --status and unknown flags.
• vp run --filter ./packages/void typecheck, vp fmt --check, vp lint all clean; full packages/void/test/unit green (2698).

🤖 Generated with Claude Code

https://claude.ai/code/session_011iZtc3xSUBc3NqapBXuYCH

---

Note

Low Risk
CLI-only observability and client-side log filtering; depends on the paired platform /requests endpoint but does not change deploy or runtime behavior.

Overview
Adds void project requests so operators can inspect edge request metering (time, method, status, type, duration) via GET /projects/:id/requests, with optional --status (e.g. 5xx, 500) and --range. This covers edge-generated 5xx and static/SPA traffic that never invokes a worker—cases void project logs cannot show.

void project logs --level error now also keeps entries whose HTTP status is 5xx, even when the worker returned an error response without throwing or logging—aligned with the platform’s server-side error predicate.

CLI wiring includes PlatformClient.getRequests, requests.ts, arg parsing/validation, help, interactive hints, MCP catalog, and docs/agent prompts. Unit tests cover the new 5xx log filter, request URL query params, and requests flag parsing.

^{Reviewed by Cursor Bugbot for commit 99dbe39. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot 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_8f604859-52dc-45bc-bf39-0d09bc9b5e12)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 25b7379c9c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot 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_ec1f9e54-f5b0-481f-8f96-7c00114aaa70)

[Brooooooklyn]

Addressed in 78cfaf1a (branch also rebased onto latest main).

Reject out-of-range exact status filters — valid. STATUS_FILTER was /^([1-5]xx|\d{3}|all)$/, so 600 / 000 / 999 were accepted and forwarded to the API, which returned an empty list rather than the documented invalid-status error. The exact-code alternative is now range-bounded to 100–599 (/^([1-5]xx|[1-5]\d{2}|all)$/), with a test covering 000, 099, 600, 999.

The same bound is applied server-side in voidzero-dev/void-platform#239, so the CLI and API validation stay in lockstep.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 78cfaf1acb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot 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_5c00afc9-c8e2-4722-903c-b963ea6e3844)