fix(web): service overview throughput uses the queried window

[Makisuo]

What

getServiceOverview resolves a 24h fallback window when the caller passes no startTime/endTime, and runs the query on that window. The rate divisor was computed from the raw inputs instead (windowDurationSeconds(input.startTime, input.endTime)), which falls back to 3600s. On the default window every throughput came out 24x too high.

The divisor now uses the resolved startTime/endTime, the same window the query ran on.

Test

New case in services.test.ts: no range passed, 100 spans, expects 100 / 86400. It fails on the old code (100 / 3600) and passes with the fix. It uses it.live because the TestClock sits at epoch 0, where the fallback window has no positive start.

Context for reviewers

This came out of investigating a reported spike on the last point of the service detail throughput chart. That chart path checked out end to end (compiled SQL matched raw counts per bucket, including the trailing bucket; the web divides every bucket by one width), so this PR does not touch it. The likely cause there is the API bucket cache serving buckets cached before reseeded local data landed. Separately worth deciding: the cache treats buckets as settled after 60s (QE_BUCKET_CACHE_FLUX_SECONDS), while the web treats the last 120s as still filling.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[maple-review-bot]

Maple review

🟢 Confidence 9/10 · safe to merge
One-line divisor fix, the only windowDurationSeconds call in the file, pinned by a test that reads 100/3600 without it.
_{quality 100/100 · no findings · tests covered · risk low}

getServiceOverview now divides throughput by the resolved window it queried instead of the raw inputs, fixing a 24x-inflated rate on the default range. Contained and safe to merge.

• getServiceOverview divides by windowDurationSeconds(startTime, endTime), the resolved window
• New it.live test asserts 100 spans over the default 24h window

What was checked

• windowDurationSeconds falls back to 3600s only when a bound is missing or unparseable (packages/query-engine/src/route-rows.ts:79), which the resolved window no longer is
• The new test fails on the old code: 100/3600 vs 100/86400 exceeds the 1e-9 tolerance
• No other divisor in services.ts uses raw inputs; getServiceHealthSnapshot already divides by its resolved window (services.ts:141), namespace-scope.ts:46 gets resolved bounds

_{9896e14 · Updated on every push. Reply "won't fix" to dismiss a finding, or mention @maple-review-bot to ask about one.}

[coderabbitai]

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 9f5fa48d-dace-48f2-be64-fa5727d26ab6

📥 Commits

Reviewing files that changed from the base of the PR and between 488ae1b and 9896e14.

📒 Files selected for processing (2)

• apps/web/src/api/warehouse/services.test.ts
• apps/web/src/api/warehouse/services.ts

 ____________________________________________________________
< If you don't finish then you're just busy, not productive. >
 ------------------------------------------------------------
  \
   \   (\__/)
       (•ㅅ•)
       / 　 づ

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}