This repository was archived by the owner on Aug 6, 2026. It is now read-only.
fix(autoresearch): clamp observed-time percentages before Progress - #3419
Closed
posthog[bot] wants to merge 1 commit into
Closed
fix(autoresearch): clamp observed-time percentages before Progress#3419posthog[bot] wants to merge 1 commit into
posthog[bot] wants to merge 1 commit into
Conversation
Per-kind observed time in the autoresearch observability panel can exceed the run's wall-clock duration (e.g. clock skew between agent-set event timestamps and the client clock), pushing the computed percentage above 100. Radix Progress rejects values over its default max and renders nothing plus a console error. Clamp the value to 0..100 before passing it to Progress, and guard against a zero total. Apply the same defensive clamp to the other unclamped percentage calculations in UsageMeter, UsageButton, and UpdateAvailableModal. Generated-By: PostHog Code Task-Id: 88b04cb6-418c-4e80-bf2f-8f8e8f5c3e18
|
Merging to
After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here |
|
React Doctor found no issues in the changed files. 🎉 Reviewed by React Doctor for commit |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The autoresearch observability panel (PostHog Code desktop app,
/code/tasks/<id>detail route) throws a React validation error when the observed time for one activity kind exceeds the run's wall-clock duration.TimeRowcomputespercentage = Math.round((value / total) * 100), wherevalueis the per-kind observed time andtotalis the run's elapsed wall-clock time. The per-kind times are derived from event timestamps, which can drift ahead of the client clock (skew between agent-set timestamps andnow), so the ratio can exceed 1 and produce a value like112. RadixProgressrejects anyvalueabove its defaultmaxof 100 — it logsInvalid prop value ... supplied to Progressand renders an empty bar. Non-fatal, but noisy in error tracking and leaves the panel looking broken.The same unclamped percentage pattern exists in
UsageMeter,UsageButton, andUpdateAvailableModal.Changes
0..100(and guard a zero total) before passing it toProgressinAutoresearchObservability.UsageMeter,UsageButton, andUpdateAvailableModal. InUsageMeterthe displayed text still shows the true (possibly >100%) figure; only the progress bar value is clamped.now) and asserts every observed-time bar renders with an in-rangearia-valuenow.How did you test this?
AutoresearchObservability.test.tsx; confirmed it fails against the pre-fix code (bar renders with noaria-valuenow) and passes with the fix.packages/ui— 41 tests pass.biome checkclean on all changed files.Automatic notifications
Created with PostHog Code from an inbox report.