fix: use Object.hasOwn instead of in operator in usage bar translator by zhangLei99586 · Pull Request #98139 · openclaw/openclaw

zhangLei99586 · 2026-06-30T12:05:55Z

Related: #98466

What Problem This Solves

key in table checks prototype chain — toString/constructor match Object.prototype instead of fallthrough.

Why This Change Was Made

Replace key in table with Object.hasOwn(table, key) in alias + case table lookup (2 lines).

User Impact

Fixes incorrect usage bar rendering when keys coincide with prototype names.

Evidence

Runtime terminal proof (Node v24.13.1):

15/15 tests passed + 2 new regression tests (translator.test.ts)
renderUsageBar(tpl, {m:"toString"}) → "owned-value" — Object.hasOwn verified

clawsweeper · 2026-06-30T12:06:54Z

Codex review: needs changes before merge. Reviewed July 1, 2026, 5:14 AM ET / 09:14 UTC.

Summary
The PR changes usage-bar alias and map lookups from prototype-chain membership checks to Object.hasOwn and adds prototype-key regression tests.

PR surface: Source 0, Tests +25. Total +25 across 2 files.

Reproducibility: yes. Source inspection of current main and v2026.6.11 shows prototype-chain in checks on user-authored alias and map case tables, so keys like toString and constructor can take the wrong lookup path.

Review metrics: none identified.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #98466
Summary: The linked issue is the canonical report for the usage-bar prototype-chain lookup bug; this PR is one candidate fix, and another open PR overlaps the same root cause.

Members:

canonical: usage-bar: in operator matches Object.prototype inherited properties #98466 - The issue body names the same translator lookup sites and expected Object.hasOwn behavior.
same_root_cause: fix(usage-bar): use Object.hasOwn instead of in operator to avoid prototype chain pollution #98503 - The PR changes the same translator lookups to Object.hasOwn for the same prototype-chain failure mode, but it is still open and not a merged superseding fix.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦞 diamond lobster ✨ media proof bonus
Patch quality: 🦪 silver shellfish
Result: blocked by patch quality or review findings.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Make the alias regression test type-safe by giving the template or alias table a narrowed type before mutating it.
Rerun the focused translator test and test type check after the test setup change.

Risk before merge

[P1] Strict test type checking should fail until the alias regression setup narrows or constructs a typed alias table before mutation.

Maintainer options:

Decide the mitigation before merge
Keep the Object.hasOwn production fix, but make the alias regression setup type-safe before merging this PR.
Pause or close
Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

[P2] There is one narrow mechanical test typing blocker that an automated repair can fix on the PR branch without changing the production lookup behavior.

Security
Cleared: The diff only narrows usage-bar lookup behavior and adds tests; it does not touch dependencies, workflows, permissions, secrets, package metadata, or code execution paths.

Review findings

[P1] Type the alias table before mutating it — src/auto-reply/usage-bar/translator.test.ts:71

Review details

Best possible solution:

Keep the Object.hasOwn production fix, but make the alias regression setup type-safe before merging this PR.

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

Yes. Source inspection of current main and v2026.6.11 shows prototype-chain in checks on user-authored alias and map case tables, so keys like toString and constructor can take the wrong lookup path.

Is this the best way to solve the issue?

Mostly yes. The production Object.hasOwn change is the narrow maintainable fix, but the PR should only merge after the alias regression setup is made type-safe.

Full review comments:

[P1] Type the alias table before mutating it — src/auto-reply/usage-bar/translator.test.ts:71
tpl() returns UsageBarTemplate, which is just Record<string, unknown>, so t.aliases remains unknown here. Strict test type checking should reject this property chain; construct a typed template shape or narrow the alias table before assigning toString.
Confidence: 0.93

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against f3ac874fd215.

Label changes

Label justifications:

P3: This is a low-blast-radius usage-footer edge-case bugfix rather than an urgent runtime outage.
rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦞 diamond lobster and patch quality is 🦪 silver shellfish.
status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (screenshot): The PR body/comment include a terminal screenshot, inspected locally, showing after-fix renderUsageBar behavior for the prototype-key alias and map paths.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body/comment include a terminal screenshot, inspected locally, showing after-fix renderUsageBar behavior for the prototype-key alias and map paths.
proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The PR body/comment include a terminal screenshot, inspected locally, showing after-fix renderUsageBar behavior for the prototype-key alias and map paths.

Evidence reviewed

PR surface:

Source 0, Tests +25. Total +25 across 2 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	1	3	3	0
Tests	1	25	0	+25
Docs	0	0	0	0
Config	0	0	0	0
Generated	0	0	0	0
Other	0	0	0	0
Total	2	28	3	+25

Acceptance criteria:

[P1] node scripts/run-vitest.mjs src/auto-reply/usage-bar/translator.test.ts.
[P1] pnpm check:test-types.

What I checked:

Repository policy read: Root AGENTS.md was read fully; its OpenClaw PR guidance on full code-path review, proof, and source/current behavior affected this review. (AGENTS.md:1, f3ac874fd215)
Current main behavior: Current main still uses key in table, lower in table, and key in cases, so inherited Object.prototype keys can be treated as lookup hits. (src/auto-reply/usage-bar/translator.ts:133, f3ac874fd215)
Latest release behavior: The latest release tag v2026.6.11 contains the same prototype-chain membership checks at the alias and map lookup sites. (src/auto-reply/usage-bar/translator.ts:133, e085fa1a3ffd)
Runtime entry point: resolveResponseUsageLine loads the configured usage template and calls renderUsageBar, making the translator part of the user-visible usage footer path. (src/auto-reply/reply/agent-runner-usage-line.ts:98, f3ac874fd215)
Template contract: Docs describe messages.usageTemplate as a custom JSON path or inline object with aliases and map cases, so own-property lookup is the appropriate data-boundary behavior. Public docs: docs/concepts/usage-tracking.md. (docs/concepts/usage-tracking.md:101, f3ac874fd215)
PR production change: The PR head changes the three implicated translator lookups to Object.hasOwn, which preserves explicit own entries and avoids prototype-chain hits. (src/auto-reply/usage-bar/translator.ts:133, 94a5d9b21588)

Likely related people:

Peetiegonzalez: Merged PR metadata for the native templated usage footer lists commits by this account that introduced the translator engine, tests, and template contract used by this bug path. (role: usage renderer commit author; confidence: high; commits: 505539c89929, f1cca6ee2716, ba7275e95974; files: src/auto-reply/usage-bar/translator.ts, src/auto-reply/usage-bar/translator.test.ts, src/auto-reply/usage-bar/template.ts)
Marvinthebored: GitHub search and PR metadata identify this account as the author of the merged native usage footer renderer and built-in footer PRs that define this usage-template surface. (role: feature PR author; confidence: high; commits: 505539c89929, b07d4c79ba16; files: src/auto-reply/usage-bar/translator.ts, src/auto-reply/usage-bar/default-template.ts, docs/concepts/usage-tracking.md)
obviyus: This account merged the native usage footer renderer PR and authored several follow-up commits tightening the usage footer template behavior and docs/tests. (role: merger and recent usage-template contributor; confidence: high; commits: d3688d978b23, 89b7e837d14d, 071c82355309; files: src/auto-reply/usage-bar/translator.ts, src/auto-reply/usage-bar/default-template.ts, docs/concepts/usage-tracking.md)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

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.

How this review workflow works

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.

zhangLei99586

@clawsweeper re-review

zhangLei99586 · 2026-07-01T02:24:38Z

@clawsweeper re-review

clawsweeper · 2026-07-01T02:24:40Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

zhangLei99586 · 2026-07-01T06:21:45Z

@clawsweeper review

The 'in' operator checks the prototype chain, so keys like 'toString', 'valueOf', or 'constructor' would incorrectly match inherited properties on vocabulary alias tables and segment case tables. Replace with Object.hasOwn() which only checks own properties.

Add focused tests proving Object.hasOwn correctly distinguishes own properties from inherited Object.prototype keys (toString, constructor) in both alias vocabulary lookup and segment case table lookup.

zhangLei99586 · 2026-07-01T06:31:08Z

@clawsweeper re-review

clawsweeper · 2026-07-01T06:31:10Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

zhangLei99586 · 2026-07-01T06:46:06Z

@clawsweeper re-review

zhangLei99586 · 2026-07-01T08:18:37Z

@clawsweeper re-review

zhangLei99586 · 2026-07-01T08:29:39Z

@clawsweeper re-review

zhangLei99586 · 2026-07-01T08:33:32Z

Runtime behavior proof — terminal output from after-fix execution:

zhangLei99586 · 2026-07-01T08:35:14Z

Runtime behavior proof (terminal output):

zhangLei99586 · 2026-07-01T08:35:50Z

@clawsweeper re-review

zhangLei99586 · 2026-07-01T08:40:42Z

@clawsweeper re-review

zhangLei99586 · 2026-07-01T08:48:10Z

@clawsweeper re-review

vincentkoc · 2026-07-01T10:43:11Z

Thanks for the patch. I’m closing this because the same usage-bar Object.hasOwn fix for #98466 has already landed through the canonical PR #98503, merged as 73e6a62.

This branch now overlaps the landed implementation, so keeping it open would just create duplicate churn.

openclaw-barnacle Bot added the size: XS label Jun 30, 2026

zhangLei99586 commented Jul 1, 2026

View reviewed changes

zhangLei99586 added 2 commits July 1, 2026 14:22

test(usage-bar): add regression tests for prototype key handling

94a5d9b

Add focused tests proving Object.hasOwn correctly distinguishes own properties from inherited Object.prototype keys (toString, constructor) in both alias vocabulary lookup and segment case table lookup.

zhangLei99586 force-pushed the fix/in-operator-prototype branch from c9d9f0e to 94a5d9b Compare July 1, 2026 06:30

clawsweeper Bot mentioned this pull request Jul 1, 2026

usage-bar: in operator matches Object.prototype inherited properties #98466

Closed

clawsweeper Bot mentioned this pull request Jul 1, 2026

fix(usage-bar): use Object.hasOwn instead of in operator to avoid prototype chain pollution #98503

Merged

vincentkoc closed this Jul 1, 2026

Uh oh!

Uh oh!

Conversation

zhangLei99586 commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

clawsweeper Bot commented Jun 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zhangLei99586 left a comment

Choose a reason for hiding this comment

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

clawsweeper Bot commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

clawsweeper Bot commented Jul 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

zhangLei99586 commented Jul 1, 2026

Uh oh!

vincentkoc commented Jul 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

zhangLei99586 commented Jun 30, 2026 •

edited

Loading

clawsweeper Bot commented Jun 30, 2026 •

edited

Loading

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading

clawsweeper Bot commented Jul 1, 2026 •

edited

Loading