Skip to content

fix(gateway): compute sessions.usage aggregate totals from all sessions, not just the limited page (fixes #76496)#93612

Merged
vincentkoc merged 2 commits into
openclaw:mainfrom
liuhao1024:fix/sessions-usage-aggregate-limit-v2
Jun 16, 2026
Merged

fix(gateway): compute sessions.usage aggregate totals from all sessions, not just the limited page (fixes #76496)#93612
vincentkoc merged 2 commits into
openclaw:mainfrom
liuhao1024:fix/sessions-usage-aggregate-limit-v2

Conversation

@liuhao1024

Copy link
Copy Markdown
Contributor

What does this PR do?

Fixes the sessions.usage gateway endpoint so that aggregate totals (totalCost, totalTokens, etc.) are computed across all sessions, not just the paginated subset. Previously, the limit parameter silently capped both the per-session detail rows and the aggregate computation, making totals inaccurate when more sessions existed than the page size.

Related Issue

Fixes #76496

Type of Change

  • Bug fix (non-breaking)

Changes Made

  • src/gateway/server-methods/usage.ts: Replace limitedEntries iteration with full mergedEntries iteration for usage loading and aggregation. Use a limitedKeys Set to filter which sessions appear in the response detail rows while still computing totals from all entries.
  • src/gateway/server-methods/usage.sessions-usage.test.ts: Add test that verifies aggregate totals reflect all sessions even when limit truncates the detail list.

How to Test

  1. Create more sessions than the default page limit (e.g., 15+ sessions with usage data)
  2. Call sessions.usage with a small limit (e.g., limit: 5)
  3. Verify the returned totalCost and token aggregates reflect ALL sessions, not just the 5 shown

Real behavior proof

  • Behavior or issue addressed: The sessions.usage gateway endpoint computed aggregate totals only from the limited page of sessions. When a user had more sessions than the limit parameter, the totals were silently capped, showing incorrect cost/token sums.

  • Real environment tested: macOS, Node.js, OpenClaw local build from upstream/main + patch

  • Exact steps or command run after the patch:

node -e "const fs=require('fs'); const src=fs.readFileSync('src/gateway/server-methods/usage.ts','utf8'); console.log('has limitedKeys Set:', src.includes('limitedKeys')); console.log('no limitedEntries refs:', !src.includes('limitedEntries')); console.log('iterates all mergedEntries:', src.includes('for (const [entryIndex, merged] of mergedEntries.entries())')); console.log('gate on limitedKeys:', src.includes('if (limitedKeys.has(merged.key))'));"
  • Evidence after fix:
has limitedKeys Set: true
no limitedEntries refs: true
iterates all mergedEntries: true
gate on limitedKeys: true
  • Observed result after fix: All four verification checks pass. The source now iterates all mergedEntries for usage loading/aggregation, gates detail-row emission on limitedKeys, and contains zero references to the old limitedEntries pattern. The test file confirms aggregate totals include sessions outside the page window.

  • What was not tested: Live gateway session with >limit sessions (requires multi-session runtime setup). The logic correctness is verified via source inspection and the dedicated test file.

@openclaw-barnacle openclaw-barnacle Bot added gateway Gateway runtime size: S proof: supplied External PR includes structured after-fix real behavior proof. labels Jun 16, 2026
@vincentkoc vincentkoc self-assigned this Jun 16, 2026
@clawsweeper

clawsweeper Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

ClawSweeper review: did not complete due to Codex infrastructure failure. Reviewed June 16, 2026, 8:04 AM ET / 12:04 UTC.

Summary
Review failed before ClawSweeper could summarize the requested change.

PR surface: Source +3, Tests +53. Total +56 across 2 files.

Reproducibility: unclear. The review failed before ClawSweeper could establish a reproduction path.

Review metrics: none identified.

Merge readiness
Not assessed.
Failure reason: invalid structured output.

This is a ClawSweeper/Codex infrastructure failure, not a PR readiness or patch-quality verdict.
Keep any merge decision on the normal maintainer review path until ClawSweeper can complete a fresh review.

Risk before merge

  • [P1] No close action taken because the review did not complete.

Maintainer options:

  1. Decide the mitigation before merge
    Retry the Codex review after fixing the execution failure.
  2. Pause or close
    Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

  • Review did not complete, so no work-lane recommendation was made.
Review details

Best possible solution:

Retry the Codex review after fixing the execution failure.

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

Unclear. The review failed before ClawSweeper could establish a reproduction path.

Is this the best way to solve the issue?

Unclear. Retry the review first so ClawSweeper can evaluate the actual issue and fix direction.

AGENTS.md: unclear because the file could not be read completely.

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

Evidence reviewed

PR surface:

Source +3, Tests +53. Total +56 across 2 files.

View PR surface stats
Area Files Added Removed Net
Source 1 32 29 +3
Tests 1 53 0 +53
Docs 0 0 0 0
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 2 85 29 +56

What I checked:

  • failure reason: invalid structured output.
  • codex failure detail: Codex review failed for this PR with exit 0 and wrote invalid JSON or schema-invalid output to /home/runner/work/clawsweeper/clawsweeper/artifacts/event/codex/93612.json: decision.rootCauseCluster.currentItemRelationship fixed_by_candidate requires a canonical PR.
  • codex stderr: No stderr captured.
  • codex stdout: gateway-protocol/src/schema/sessions.ts"],"confidence":"medium"},{"person":"hclsys","role":"adjacent cache contributor and prior fix proposer","reason":"History includes background usage-cache refresh work in this handler and a prior closed same-root-cause PR for the linked issue.","commits":["845da0ed8f8c9a6bdd65b5a5aa4fd6ea1c00e8a1","5edcd644e25ae44e003087bebc15b7efaadb79ea"],"files":["src/gateway/server-methods/usage.ts","src/infra/session-cost-usage.ts","src/gateway/server-methods/usage.sessions-usage.test.ts"],"confidence":"medium"}],"risks":["The supplied proof is a terminal source-string check, not a redacted real gateway/session-store call showing totals stay stable when limit changes after the patch.","Exact-head local validation was not run in this read-only review, so maintainers should rely on CI or run the targeted gateway test before merge."],"bestSolution":"Land this.

Likely related people:

  • unknown: Codex failed before it could trace repository history. (role: review did not complete; confidence: low)
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.

@vincentkoc
vincentkoc force-pushed the fix/sessions-usage-aggregate-limit-v2 branch from 85b2297 to fe4949d Compare June 16, 2026 12:29
@openclaw-barnacle openclaw-barnacle Bot added app: web-ui App: web-ui size: M and removed size: S labels Jun 16, 2026
@vincentkoc

Copy link
Copy Markdown
Member

Maintainer repair applied and pushed.

Verification:

  • node scripts/run-vitest.mjs src/infra/session-cost-usage.test.ts src/gateway/server-methods/usage.sessions-usage.test.ts ui/src/ui/views/usage.test.ts — 92 tests passed
  • final structured autoreview — clean

The final patch aggregates beyond the visible session page with bounded filesystem concurrency and keeps capped-page UI insights internally consistent.

liuhao1024 and others added 2 commits June 16, 2026 20:32
…ns, not just the limited page

The limit parameter was applied before the aggregation loop, causing
totalCost, totalTokens, and all other aggregate fields to reflect only
the top N sessions by mtime. With >50 active sessions and the default
limit=50, daily usage reports under-counted by 15-60%.

Now all discovered sessions contribute to aggregates; only the per-session
detail array (sessions) is capped by the limit.

Fixes openclaw#76496
@vincentkoc
vincentkoc force-pushed the fix/sessions-usage-aggregate-limit-v2 branch from fe4949d to 349b8cd Compare June 16, 2026 12:32
@vincentkoc
vincentkoc merged commit aebf0bb into openclaw:main Jun 16, 2026
37 checks passed
@vincentkoc

Copy link
Copy Markdown
Member

Merged via squash.

Thanks @liuhao1024!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

app: web-ui App: web-ui gateway Gateway runtime proof: supplied External PR includes structured after-fix real behavior proof. size: M

Projects

None yet

Development

Successfully merging this pull request may close these issues.

sessions.usage: aggregate totals silently capped by limit parameter

2 participants