Skip to content

fix(tray): show real percentage when no declared primary candidate is present - #24

Open
Abhijith14 wants to merge 1 commit into
openusage-community:mainfrom
Abhijith14:fix/tray-percent-without-primary-candidate
Open

fix(tray): show real percentage when no declared primary candidate is present#24
Abhijith14 wants to merge 1 commit into
openusage-community:mainfrom
Abhijith14:fix/tray-percent-without-primary-candidate

Conversation

@Abhijith14

@Abhijith14 Abhijith14 commented Jul 27, 2026

Copy link
Copy Markdown

What

When none of a plugin's declared primary candidates appear in the runtime data, getTrayPrimaryBars now falls back to the first available progress line instead of leaving fraction undefined.

Why

The tray shows --% for plans that expose a perfectly usable progress line, just not the one the manifest declares.

Concrete case — a usage-based Codex account (plan: Self_serve_business_usage_based):

  • codex/plugin.json marks only Session with primaryOrder, so primary_candidates == ["Session"].
  • That plan's payload contains no Session line at all. Its only progress line is Credits (used: 1000.0, limit: 1000.0).
  • primaryLabel therefore resolves to undefined, the if (primaryLabel) branch is skipped, fraction stays undefined, and formatTrayPercentText(undefined) returns "--%".

The panel UI renders this account correctly (0 credits left / 1,000 credits) — only the tray loses the number, which makes it look like a data problem rather than a metric-selection one.

formatTrayPercentText itself is fine: it already handles 0 correctly and has a test asserting formatTrayPercentText(0) === "0%". The fraction simply never reached it.

Fix

If no declared candidate matches, use the first progress line present in the data. With the case above this yields limit - used = 0 over limit 1000 in left mode → 0%.

Plugins that declare no candidates at all are still skipped by the existing guard, so this does not surface plugins that have no progress concept.

Testing

  • New regression test covering a declared candidate that is absent from the data, asserting fraction: 0 rather than undefined.
  • Full suite: 1156 passed / 66 files.
  • Verified on a real affected account: tray changed from --% to 0%.

No visual changes to icon rendering in this PR.

@github-actions github-actions Bot added the core label Jul 27, 2026
A plan can expose progress lines that are absent from its plugin manifest's
declared primary candidates. Usage-based Codex accounts
(Self_serve_business_usage_based) report only a "Credits" progress line and
never "Session", which is the only candidate codex declares via primaryOrder.

getTrayPrimaryBars then matched no label, left fraction undefined, and the
tray rendered "--%" even though a perfectly usable progress line was present
(used 1000 / limit 1000).

Fall back to the first progress line in the runtime data when none of the
declared candidates match, so the tray shows a real number. Plugins that
declare no candidates at all are still skipped, exactly as before.
@Abhijith14
Abhijith14 force-pushed the fix/tray-percent-without-primary-candidate branch from 9ee1eda to 34e84bc Compare July 27, 2026 00:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant