feat(telemetry): accept identifier-free update outcomes

[roboclaw-bot]

Summary

Add the receiver companion for identifier-free terminal update outcomes on the existing POST /api/latest-version endpoint. Finalization only: no merge, deployment, production outcome requests, provisioning, paid resources, or credential changes.

• Strict schema-2/event update_result: 18 mandatory flat public-label fields; no IDs, geography, raw User-Agent, logs, private versions or free-form diagnostics. Valid UTF-8 and at most 4096 upload bytes, including BOM/whitespace. Fixed UA openclaw-update-result/1 keeps malformed outcomes off the daily path. Dedicated outcome storage never falls back to TELEMETRY.
• P2 quota regression fixed: decide recording quota once before reading GET/POST uploads. Exhausted callers receive the existing latest-version answer even while a chunked upload remains unfinished; neither dataset is written. Legacy GET/schema-1 behavior and geography columns stay unchanged.
• P1 rollout coupling fixed: removed UPDATE_RESULTS from default production Wrangler configuration. It now exactly matches current main's bindings (TELEMETRY and RATE_LIMIT); the existing main-push deployment workflow is unchanged. A separately authorized rollout must explicitly supply the separate dataset binding and verify delivery/retention.
• Capability contract: HEAD the same full configured endpoint. Binding present → empty 204, OpenClaw-Update-Results: 2; absent → empty 503 without capability header. Both use Cache-Control: no-store. HEAD never reads an upload/geography, consumes recording quota, writes analytics, or fetches a version. Presence is capability, not production-readiness proof.
• Agreed companion-client contract for openclaw/openclaw#154067: two requests per outcome attempt (HEAD then conditional POST), fixed UA, a shared three-second deadline, no redirects, and an opt-out recheck after HEAD. Old receivers (405) and unconfigured receivers (503) receive no outcome payload. Daily GET and opt-in schema-1 POST stay single requests.
• Approved policy, September 23: Json approved outcomes on by default, like update checks; schema-1 feature statistics remain opt-in. Update-policy opt-outs, Nix and CI suppression apply to outcomes. DO_NOT_TRACK affects feature statistics, not update checks/outcomes. The paired client is being finalized to the same contract; receiver disclosure is not being changed back to separate opt-in.
• All four version fields preserve patch values 0–999999 without leading zeroes, including 2026.8.33 and 2026.8.123; year/month/revision/beta restrictions remain unchanged.

Verification — exact receiver head

Tested/published candidate: d7c2aac798816662e6144e514b873aa7916ce504. Forward-only merge of previous head 20e22a5f5c1c5c984700b589215369d448969fef and pinned upstream main 1d9ff5c35e71f33b75428579015541d08fbd2c52. Resolved the handler conflict while preserving main's compiled-vocabulary simplification and refreshed tooling/lockfile. No force push or replacement of others' changes.

• Node 24.15.0, npm run check: deterministic vocabulary + TypeScript + 13 files / 492 tests passed. Includes 79 outcome tests and 9 pinned-workerd runtime tests.
• Standard installed AutoReview, pre-commit staged local candidate against pinned main, Codex P0–P2, no custom prompt: scoped-clean / no actionable findings. Static review is separate from executed runtime proof.
• npx wrangler deploy --dry-run, Wrangler 4.136.3: passed, no deployment. Output lists only env.TELEMETRY (openclaw_telemetry) and env.RATE_LIMIT (20 requests/60s); no UPDATE_RESULTS binding.
• Exact-head GitHub CI: Deploy / check run 35927327906 SUCCESS; deploy SKIPPED (pull request), [code]smith SKIPPED. GitHub reports MERGEABLE, still draft.
• Shared synthetic fixture SHA-256 remains 2eb0cffc863c8b3b5335ffcc0a38bcc8495264e8c988647419b328fce0dba754, 18 fields. Storage columns unchanged.

Real behavior proof (local HTTP, not production)

Executed the actual bundled Worker in Wrangler's pinned workerd runtime, using loopback HTTP, synthetic fixtures, isolated sinks and a stubbed npm response. Committed harness: test/latest-version-runtime.test.mjs.

Scenario	Observed result
Published 20e22a5, exhausted quota, unfinished chunked POST, both outcome and legacy UA	No answer within deterministic 500 ms bound; confirms regression
Pinned main 1d9ff5c, same unfinished uploads	200 latest-version answer, exactly one quota decision, zero daily/outcome writes
Candidate d7c2aac, same unfinished uploads	200 latest-version answer without ending upload, exactly one quota decision, zero writes/geography reads
Legacy main HEAD	405, no capability, zero analytics/quota/version fetches
Candidate HEAD with / without outcome binding	Empty 204 + capability 2 / empty 503 with no capability; no-store; zero body/geography reads, quota decisions, analytics writes or outbound fetches
Default bindings, valid outcome POST	Fixed 503 update_results_unavailable; no daily fallback or upstream fetch
Valid shared 18-field outcome	200; exact 17 outcome blobs, schema double 2 and target-version index; no daily row
Extra ID, private version, >4096 bytes, malformed UTF-8	400 invalid_update_result; neither dataset receives a row
Legacy daily and schema-1 regression suite	Pass; existing daily geography/allowlisting and version behavior preserved

The initial new Node HTTP harness accidentally used the host environment-proxy global agent; this produced a non-JSON proxy error instead of reaching loopback. The harness now uses an explicit local HTTP Agent and closes/rejects on failures. The focused 9-test runtime suite and full 492-test suite then passed; no product assertions or deadlines were weakened.

Remaining rollout and coordination

Receiver source is prepared for coordinated merge readiness; this PR remains draft until both PRs and exact-head CI are checked together. No ready transition, merge or deployment was performed here. Production dataset provisioning/delivery and SQL remain unverified and separately authorized work. HEAD is not a storage health check. Version-response failure may follow recording; no exactly-once or retry guarantee. Without the fixed UA, undecodable bodies retain legacy invalid-feature behavior; companion clients must always send it.

The existing public fork remains owned/published by the same managed identity roboclaw-bot; no alternate credentials or upstream branch writes.

Contributor credit: Json (@fuller-stack-dev), Peter (@steipete), and Vincent (@vincentkoc).

Work sessions

• Original discussion with @fuller-stack-dev
• Implementation and verification

---

View the OpenClaw team session

[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 23, 2026, 6:26 PM ET / 22:26 UTC (Revision 3).

ClawSweeper review

What this changes

The branch adds a strictly validated update-outcome request to the telemetry Worker, a capability check, separate analytics storage, documentation, and runtime coverage.

Merge readiness

⛔ Blocked before merge - 4 items remain

Current main does not accept update outcomes. The revised PR addresses the prior quota and deployment-binding findings and has relevant local Worker HTTP proof. It remains draft while the default-on policy and coordinated rollout need maintainer confirmation.

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

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	The patch is focused and has relevant local HTTP proof; rollout and policy ownership remain human decisions.
Proof confidence	🐚 platinum hermit (4/6)	Sufficient (terminal): The reported exact-head run exercises the bundled Worker over local workerd HTTP with a real HTTP client, isolated analytics sinks, and a stubbed npm response; it observes accepted and rejected outcomes, capability responses, and recovery of the unfinished-upload quota path. Production delivery is a separate rollout check. Existing daily storage columns and the default binding remain unchanged, so no existing-state migration is needed.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (terminal): The reported exact-head run exercises the bundled Worker over local workerd HTTP with a real HTTP client, isolated analytics sinks, and a stubbed npm response; it observes accepted and rejected outcomes, capability responses, and recovery of the unfinished-upload quota path. Production delivery is a separate rollout check. Existing daily storage columns and the default binding remain unchanged, so no existing-state migration is needed.
Evidence reviewed	7 items	Current main lacks outcome handling: Main handles GET and POST as daily update checks and returns 405 for HEAD; the requested receiver behavior remains unique to this PR. Revised quota path: The introduced handler checks recording quota before reading a POST body and returns the version answer when quota is exhausted. Isolated storage and staged deployment: The outcome write uses only UPDATE_RESULTS, while the production Wrangler configuration retains only TELEMETRY. The existing main-push workflow deploys that configuration.
Findings	None	None.
Security	None	None.

How this fits together

The telemetry Worker receives OpenClaw update checks and returns the latest version. This branch lets it route bounded update outcomes to a separate dataset while keeping daily telemetry on its existing path.

flowchart LR
  A[Update client] --> B[Latest-version endpoint]
  B --> C{Request type}
  C -->|HEAD| D[Outcome capability response]
  C -->|Daily check| E[Daily telemetry dataset]
  C -->|Valid outcome| F[Separate outcome dataset]
  B --> G[Latest-version answer]

Loading

Decision needed

Question	Recommendation
May this receiver land with outcome collection disabled while the separate dataset and paired default-on client await an authorized rollout?	Stage the receiver first: Confirm the policy and merge the unbound receiver, then authorize and verify the dataset before releasing the client.

Why: The staging boundary is technically explicit, but activation and the reported default-on policy require an accountable maintainer decision.

Before merge

• Resolve merge risk (P1) - The default deployment has no outcome dataset, so HEAD will return 503 and a released companion client will suppress outcome reports until the separate dataset is authorized, deployed, and verified.
• Resolve merge risk (P1) - The PR body reports approval for default-on outcomes even when feature telemetry is off, but the supplied target-repository discussion does not independently record that policy decision.
• Complete next step (P2) - Confirm the reported default-on policy approval and authorize the receiver, dataset, and companion-client release sequence before merge.
• Resolve maintainer decision - Resolve the maintainer decision shown above before merge.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Code and test growth	production net +102 lines, tests net +345 lines	The added receiver path has focused validation and runtime coverage; production growth implements the stated separate outcome contract.

Merge-risk options

Maintainer options:

1. Approve staged activation (recommended)
   Keep the production outcome binding absent at merge and require a verified dataset rollout before the companion client ships.
2. Pause for joint readiness
   Keep this PR open until receiver deployment, dataset delivery, and client release sequencing can be reviewed together.

Technical review

Best possible solution:

Confirm the collection policy, land the receiver in its unbound state if approved, and verify dataset delivery and retention before releasing the paired default-on client.

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

Not applicable to the feature request. The prior quota regression has a concrete unfinished-upload scenario in the committed local HTTP harness.

Is this the best way to solve the issue?

Yes for the receiver boundary: strict labels, a separate dataset, and an unbound default deployment limit collection. The release sequence and default-on policy still need confirmation.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning medium; reviewed against 1d9ff5c35e71.

Labels

Label changes:

No label changes.

Label justifications:

• P2: This is a bounded telemetry capability with a staged rollout and no demonstrated current-user outage.
• merge-risk: 🚨 availability: Without the separately deployed dataset, the new capability check returns 503 and the paired client cannot submit outcomes.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit 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 reported exact-head run exercises the bundled Worker over local workerd HTTP with a real HTTP client, isolated analytics sinks, and a stubbed npm response; it observes accepted and rejected outcomes, capability responses, and recovery of the unfinished-upload quota path. Production delivery is a separate rollout check. Existing daily storage columns and the default binding remain unchanged, so no existing-state migration is needed.
• proof: sufficient: Contributor real behavior proof is sufficient. The reported exact-head run exercises the bundled Worker over local workerd HTTP with a real HTTP client, isolated analytics sinks, and a stubbed npm response; it observes accepted and rejected outcomes, capability responses, and recovery of the unfinished-upload quota path. Production delivery is a separate rollout check. Existing daily storage columns and the default binding remain unchanged, so no existing-state migration is needed.

Evidence

What I checked:

• Current main lacks outcome handling: Main handles GET and POST as daily update checks and returns 405 for HEAD; the requested receiver behavior remains unique to this PR. (src/index.ts:119, 1d9ff5c35e71)
• Revised quota path: The introduced handler checks recording quota before reading a POST body and returns the version answer when quota is exhausted. (src/index.ts:119, d7c2aac79881)
• Isolated storage and staged deployment: The outcome write uses only UPDATE_RESULTS, while the production Wrangler configuration retains only TELEMETRY. The existing main-push workflow deploys that configuration. (wrangler.jsonc:22, d7c2aac79881)
• Relevant runtime proof: The PR body reports an exact-head local workerd HTTP run. The committed harness exercises bound and unbound HEAD responses, a valid outcome, rejected uploads, and an unfinished quota-exhausted POST through the Worker entrypoint. Production dataset delivery remains unverified. (test/latest-version-runtime.test.mjs:119, d7c2aac79881)
• Companion-client dependency signal: The PR body explicitly claims a paired client contract with feat: report update outcomes by default without identifiers openclaw#154067: HEAD precedes a conditional outcome POST. The client implementation itself was not established by the target checkout. (docs/update-results.md:25, d7c2aac79881)
• Rollout boundary: The new contract says the separate dataset must be deployed and verified before the default-on client is released; the default deployment deliberately leaves the binding absent. (docs/update-results.md:15, d7c2aac79881)

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 the maintainer's default-on policy confirmation and the authorized receiver-to-client rollout 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 (2 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