feat(telemetry): accept identifier-free update outcomes

[roboclaw-bot]

Summary

Add a receiver for strictly validated, identifier-free terminal update outcomes on POST /api/latest-version, with a side-effect-free HEAD capability check. Schema-2 outcomes use a separate optional dataset and never fall back to daily telemetry. The existing recording quota is checked once before reading uploads, preserving fast version answers for exhausted callers with unfinished bodies.

The contract accepts 18 mandatory public-label fields, rejects unknown keys, malformed UTF-8, and uploads over 4096 bytes, and stores no identifiers, geography, raw User-Agent, logs, or free-form diagnostics. Documentation and the rendered disclosure explain the companion client's default-on outcome policy and unconditional CI suppression. Daily checks and optional schema-1 feature statistics retain their existing behavior.

Staged rollout

UPDATE_RESULTS is deliberately absent from production configuration. Merging deploys the unbound receiver through the existing main-push workflow; HEAD returns 503 without capability until a separately authorized rollout supplies the outcome binding. Dataset delivery and retention must be verified before releasing or activating the default-on companion client in openclaw/openclaw#154067. Capability is not production-readiness proof. No production outcome requests, dataset provisioning, credentials changes, or manual deployment are part of this PR.

Validation

Current candidate: 00c6a4325f638284f178a0eb8c7ac7b577d55278, integrating main's refreshed tooling. The original contributor commits and all three human co-author trailers are preserved; the maintainer added the Unreleased entry.

• Independent Codex AutoReview of the complete candidate at P0–P2: scoped-clean, no actionable findings.
• Exact-head GitHub check: https://github.com/openclaw/telemetry/actions/runs/36672910868 — success; deployment skipped for the PR.
• The committed workerd HTTP tests cover capability with/without a binding, missing-store failure without daily fallback, the shared valid fixture, rejected private/oversized/malformed payloads, and unfinished quota-exhausted uploads. Legacy daily/schema-1 behavior remains covered.
• Fresh remote Linux proof, Node 24.19.0 / npm 11.17.0: npm ci && npm run check && npx wrangler deploy --dry-run && npm audit passed — deterministic vocabulary, TypeScript, 492 tests in 13 files including all 79 outcome tests and all nine workerd HTTP tests, Worker build, and zero vulnerabilities. The build lists only TELEMETRY and RATE_LIMIT; UPDATE_RESULTS remains absent. No production delivery is claimed.

Rendered before/after

Actual renderHomePage() output served over local HTTP in the existing Chrome profile, light theme, 1000 × 1600 viewport, full-page captures. Before is main 7388b9e; after is this candidate. Both captures were inspected and contain only the synthetic public disclosure and example payload.

Thanks @roboclaw-bot, @fuller-stack-dev, @steipete, and @vincentkoc.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: blocked before merge. Reviewed September 30, 2026, 1:29 AM ET / 05:29 UTC (Revision 9).

ClawSweeper review

What this changes

The branch adds a strictly validated update-outcome receiver, a capability check, separate analytics storage, collection disclosures, and HTTP coverage to the telemetry Worker.

Merge readiness

⛔ Blocked before merge - 3 items remain

Current main does not accept update outcomes, and this PR remains useful. The earlier quota and disclosure findings are resolved; the remaining blocker is telemetry-owner approval of the staged rollout before the default-on companion client is released.

Priority: P2
Reviewed head: 00c6a4325f638284f178a0eb8c7ac7b577d55278
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The receiver has strong local production-path coverage and no actionable patch finding; rollout approval remains a separate merge gate.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (terminal): The contributor reports passing after-fix HTTP checks of the bundled production Worker in local workerd for capability responses, separate outcome writes, rejected uploads, and quota recovery; prepared screenshots directly show the changed disclosure. The current-head check passed. Production delivery remains a separate rollout gate. The new dataset is separate and unbound, so existing stored rows need no migration.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (terminal): The contributor reports passing after-fix HTTP checks of the bundled production Worker in local workerd for capability responses, separate outcome writes, rejected uploads, and quota recovery; prepared screenshots directly show the changed disclosure. The current-head check passed. Production delivery remains a separate rollout gate. The new dataset is separate and unbound, so existing stored rows need no migration.
Evidence reviewed	7 items	Current main lacks the receiver: The default branch serves GET and POST update checks but has no schema-2 outcome write or HEAD capability response. Introduced receiver: The branch checks recording quota before reading uploads, validates schema-2 outcomes, writes them through UPDATE_RESULTS, and exposes binding presence through HEAD. Production remains unbound: The production configuration binds only the existing TELEMETRY dataset; the new capability therefore returns 503 until a separate rollout binds UPDATE_RESULTS.
Findings	None	None.
Security	None	None.

How this fits together

The telemetry Worker receives OpenClaw update requests and returns the latest published version. The new path accepts a terminal update outcome and writes bounded labels to a separate analytics dataset when that dataset is bound.

flowchart LR
  A[OpenClaw update client] --> B[Capability check]
  B --> C{Outcome dataset bound?}
  C -->|No| D[Unavailable response]
  C -->|Yes| E[Outcome upload]
  E --> F[Quota and validation]
  F --> G[Separate analytics dataset]
  F --> H[Latest version response]

Loading

Decision needed

Question	Recommendation
May this unbound receiver merge now, with outcome dataset activation and delivery verification required before the default-on companion client is released?	Approve staged rollout: Merge the unbound receiver, then separately authorize and verify dataset activation before the client release.

Why: The code deliberately leaves collection unavailable in production, and coordinating activation with the companion release requires an accountable telemetry-owner decision.

Before merge

• Resolve merge risk (P1) - Production has no outcome dataset binding, so its capability check returns 503 and outcome reports remain unavailable. The telemetry owner has not approved the receiver-first sequence and the required dataset-delivery check before the default-on companion client is released.
• Complete next step (P2) - Obtain telemetry-owner approval of the unbound receiver merge and the separate dataset-verification gate before the default-on companion client release.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production and test growth	production +120/-18, tests and fixture +357/-4	The production growth defines the bounded receiver and separate storage contract, with a larger test addition covering its HTTP and validation boundaries.

Merge-risk options

Maintainer options:

1. Approve staged rollout (recommended)
   Confirm that the receiver may merge unbound and require verified dataset delivery before the companion client release.
2. Pause for rollout design
   Leave the PR open while the telemetry owner determines another activation sequence.

Technical review

Best possible solution:

Merge the receiver only after the telemetry owner approves the staged sequence; separately bind the outcome dataset and verify delivery and retention before the companion client release.

Do we have a high-confidence way to reproduce the issue?

Not applicable as a feature PR. Current main lacks this receiver, while the branch's local Worker HTTP harness exercises the new path.

Is this the best way to solve the issue?

Yes for the receiver implementation: strict validation and separate storage preserve the daily telemetry path. The staged production sequence still needs telemetry-owner approval.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against 7388b9e26064.

Labels

Label changes:

No label changes.

Label justifications:

• P2: This is a bounded telemetry capability with local Worker proof and a remaining rollout decision.
• merge-risk: 🚨 availability: The unbound production receiver advertises no outcome capability until a separately authorized dataset rollout succeeds.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The contributor reports passing after-fix HTTP checks of the bundled production Worker in local workerd for capability responses, separate outcome writes, rejected uploads, and quota recovery; prepared screenshots directly show the changed disclosure. The current-head check passed. Production delivery remains a separate rollout gate. The new dataset is separate and unbound, so existing stored rows need no migration.
• proof: sufficient: Contributor real behavior proof is sufficient. The contributor reports passing after-fix HTTP checks of the bundled production Worker in local workerd for capability responses, separate outcome writes, rejected uploads, and quota recovery; prepared screenshots directly show the changed disclosure. The current-head check passed. Production delivery remains a separate rollout gate. The new dataset is separate and unbound, so existing stored rows need no migration.

Evidence

What I checked:

• Current main lacks the receiver: The default branch serves GET and POST update checks but has no schema-2 outcome write or HEAD capability response. (src/index.ts:119, 7388b9e26064)
• Introduced receiver: The branch checks recording quota before reading uploads, validates schema-2 outcomes, writes them through UPDATE_RESULTS, and exposes binding presence through HEAD. (src/index.ts:119, 00c6a4325f63)
• Production remains unbound: The production configuration binds only the existing TELEMETRY dataset; the new capability therefore returns 503 until a separate rollout binds UPDATE_RESULTS. (wrangler.jsonc:22, 00c6a4325f63)
• Production-path local coverage: The committed harness sends HTTP requests to the bundled Worker in workerd and checks bound and unbound capability responses, outcome isolation, invalid uploads, and an unfinished quota-exhausted upload. The contributor reported the focused and full suites passing on the preceding substantive head; the exact current head has a successful check. (test/latest-version-runtime.test.mjs:96, 00c6a4325f63)
• Disclosure proof: The PR's prepared before-and-after screenshots show the rendered page adding the outcome disclosure and corrected CI policy. They prove the visible page change, not production dataset delivery. (src/page.ts:58, 00c6a4325f63)
• Rollout request remains unapproved: The contributor's September 28 comment asks telemetry owners to approve an unbound-receiver merge followed by separately authorized dataset verification; it expressly says the request does not record owner approval. feat(telemetry): accept identifier-free update outcomes #23 (comment).

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• vincentkoc: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

• Record telemetry-owner approval of the receiver-first, dataset-before-client-release sequence.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (8 earlier review cycles)

• reviewed 2026-09-19T17:34:50.793Z sha 960dd65 :: needs real behavior proof before merge. :: [P1] Keep the production outcome binding behind rollout approval | [P2] Preserve the quota-exhausted response path before reading uploads
• reviewed 2026-09-23T18:55:38.128Z sha 20e22a5 :: needs real behavior proof before merge. :: [P1] Gate the production outcome binding behind rollout approval | [P2] Restore the quota-exhausted version-response path | [P2] Match outcome disclosure to the companion client's consent policy
• reviewed 2026-09-23T22:26:23.260Z sha d7c2aac :: blocked before merge. :: none
• reviewed 2026-09-25T02:40:16.333Z sha d7c2aac :: blocked before merge. :: [P2] Align the CI outcome disclosure with the companion client
• reviewed 2026-09-25T04:28:52.515Z sha a844927 :: blocked before merge. :: [P2] Correct the rendered privacy page's CI outcome policy
• reviewed 2026-09-25T06:01:53.411Z sha a844927 :: blocked before merge. :: [P2] Correct the rendered page's CI outcome policy
• reviewed 2026-09-27T12:55:52.384Z sha a844927 :: blocked before merge. :: [P2] Correct both rendered CI outcome statements
• reviewed 2026-09-28T06:57:06.062Z sha 3465d1f :: blocked before merge. :: none

[roboclaw-bot]

@steipete @vincentkoc — Json (@fuller-stack-dev) renewed the request to land both update-ping PRs. Please review exact receiver head 3465d1fd8921f677251126a68f5a32abdcf611cd and have an authorized telemetry maintainer merge through the normal repository path.

Both rendered CI statements are corrected: truthy CI always suppresses outcomes, even with a replacement endpoint. Regression reproduced RED, then 4/4 focused and 492/492 full tests passed; standard pre-commit AutoReview P0–P2 (no custom prompt) is scoped-clean; exact-head CI is green.

UPDATE_RESULTS remains absent; bindings/deploy workflow and default-on companion policy are unchanged. Please confirm the staged unbound-receiver / separately authorized dataset-verification-before-client-release sequence in your review. No production requests, provisioning or manual deployment were performed. roboclaw-bot has upstream READ only, so cannot merge; that same restriction blocked the inspected before/after screenshot attachments, whose PR delivery remains incomplete. This requests maintainer action; it does not record owner approval or an accepted handoff.

[steipete]

Landed as fe0d0b706c0ddbec4b8a54a3a3c6b5cff5667f61, preserving all three human co-author credits and adding the maintainer changelog entry.

Fresh remote Linux proof on Node 24.19.0/npm 11.17.0: npm ci && npm run check && npx wrangler deploy --dry-run && npm audit passed — vocabulary consistency, TypeScript, 492 tests across 13 files including all 79 outcome tests and nine workerd HTTP tests, Worker build, and zero vulnerabilities. Independent Codex AutoReview of the complete candidate found no actionable P0–P2 findings. The PR includes inspected before/after captures of the real rendered page using synthetic local content.

Exact-head PR CI passed. The resulting main check, deployment, and CodeQL checks are green: https://github.com/openclaw/telemetry/actions/runs/36673816182.

The receiver is staged unbound: UPDATE_RESULTS remains absent from the production configuration, and this merge does not activate outcome collection. Production dataset activation and delivery/retention verification remain separate prerequisites before releasing or activating the paired default-on client. No production outcome submissions or dataset provisioning were performed here.