[diegosouzapw]

Summary

Ports an upstream fix — quota reset timestamp parsing for numeric-string Unix timestamps.

OmniRoute's parseResetTime already handled number Unix-seconds via the < 1e12 ? * 1000 : value heuristic, but the string branch passed everything to new Date(str). When a provider returned the reset timestamp as a numeric string (e.g. "1700000000"), new Date(str) returned Invalid Date, the try/catch swallowed it, and the reset window was silently dropped from quota snapshots (showing as "no reset" in the UI).

Numeric strings (/^\d+$/) are now detected and treated as Unix timestamps with the same seconds-vs-ms heuristic. ISO/parseable strings are untouched. Applied symmetrically in both open-sse/services/usage.ts::parseResetTime and open-sse/services/codexUsageQuotas.ts::parseResetTime.

Changes

• open-sse/services/usage.ts — string branch detects /^\d+$/ and routes through the < 1e12 ms/sec heuristic.
• open-sse/services/codexUsageQuotas.ts — same logic, refactored ternary into if/else for clarity.
• tests/unit/usage-utils.test.ts — 2 new cases (seconds-string, ms-string) covering the gap.

Validation (Hard Rule #18 — TDD)

• RED proof: before the fix, __testing.parseResetTime("1700000000") returned null (logged in PR work).
• GREEN: after the fix, both new tests pass. node --import tsx/esm --test tests/unit/usage-utils.test.ts → 47/47.
• Related quota/usage suites green: usage-extractor + quota-pool-usage-shape + copilot-usage + api-key-usage-limits → 27/27.
• npm run typecheck:core → clean.
• npm run check:docs-sync → PASS (41 i18n mirrors validated).
• npx eslint on touched files → 0 warnings.

Attribution

Inspired by upstream contribution.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request updates the parseResetTime function in both codexUsageQuotas.ts and usage.ts to support parsing numeric strings as Unix timestamps, and adds corresponding unit tests. The review feedback suggests refining the generic digit regex to specifically match 10-digit or 13-digit timestamps to prevent false positives from other numeric date formats like YYYYMMDD.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using a generic /^\d+$/ regex matches any numeric string of any length. This can lead to false positives if a provider returns other numeric date formats (such as an 8-digit YYYYMMDD or a 14-digit YYYYMMDDHHMMSS string), which would then be incorrectly parsed as a Unix timestamp (e.g., 20260425 would be parsed as a timestamp in seconds, resulting in an incorrect date in 1970).

Restricting the regex to exactly 10 digits (seconds) or 13 digits (milliseconds) via /^\d{10}$|^\d{13}$/ is much more robust and specifically targets standard Unix timestamps while avoiding these false positives.

Suggested change

	if (/^\d+$/.test(resetValue)) {
	if (/^\d{10}$|^\d{13}$/.test(resetValue)) {

[gemini-code-assist]

Using a generic /^\d+$/ regex matches any numeric string of any length. This can lead to false positives if a provider returns other numeric date formats (such as an 8-digit YYYYMMDD or a 14-digit YYYYMMDDHHMMSS string), which would then be incorrectly parsed as a Unix timestamp (e.g., 20260425 would be parsed as a timestamp in seconds, resulting in an incorrect date in 1970).

Restricting the regex to exactly 10 digits (seconds) or 13 digits (milliseconds) via /^\d{10}$|^\d{13}$/ is much more robust and specifically targets standard Unix timestamps while avoiding these false positives.

Suggested change

	if (/^\d+$/.test(resetValue)) {
	if (/^\d{10}$|^\d{13}$/.test(resetValue)) {