test(combo): revive PR-010 targetExhaustion unit tests - #191
Conversation
…havior The 3 quota-path cases asserted a mental model that diverged from applyComboTargetExhaustion's real semantics, so they failed against the release code: - isProviderExhaustedReason reads reason/creditsExhausted/dailyQuotaExhausted, not error.code → signal exhaustion via creditsExhausted/reason. - classifyErrorText flags 'quota exceeded' (not 'exhausted your quota') as QUOTA_EXHAUSTED → use a matched phrase. - openai is NOT a per-model-quota provider; gemini is → use gemini for the per-model-quota (advance, don't exhaust) case. Each test keeps its original intent; only the inputs/provider are corrected to exercise the real code path. 13/13 green. Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
…runner The new open-sse/services/combo/__tests__/targetExhaustion.test.ts matched vitest.config.ts's include glob but NOT vitest.mcp.config.ts (the config that test:vitest actually runs in CI), so check:test-discovery flagged it as an orphan that no runner collects. Register the combo/__tests__ glob in vitest.mcp.config.ts and mirror it in the check-test-discovery COLLECTORS so the suite runs in the blocking test-vitest job. 13/13 green; discovery OK. Co-authored-by: diegosouzapw <diegosouza.pw@gmail.com>
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
|
Warning Review limit reached
Next review available in: 25 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
Note
|
L17 Latency Budget ReportChecked against: budgets/rest-endpoints.yaml. |
|
…uzapw#12601) Dependabot alerts #196–#199 — four HIGH advisories on fast-uri (GHSA-jqff-g426-hqxp, GHSA-fph4-wmhf-6fwf, GHSA-f65p-4m7j-42xc, GHSA-5jgf-p345-68v8), all patched in 3.1.6. The root package-lock.json was already on a patched fast-uri (3.1.7) — those alerts close on their own with the next scan. `electron/package-lock.json` is a second lockfile and was still pinning 3.1.5, which is what these four alerts are actually reporting. Transitive, one copy, pulled by ajv (`^3.0.1`), so a package-lock-only update lifts it without touching any manifest. The diff is three lines: version, resolved and integrity for that single entry. check:lockfile and check:tracked-artifacts pass. Not fixed here: extract-zip (#191, HIGH, <= 2.0.1) has no published patch. It comes in through @openai/codex-security and is dev-scope; it needs either an upstream release or a decision to drop/replace the dependency, neither of which belongs in a lockfile bump.
1 participant
Revives the unit tests for
open-sse/services/combo/targetExhaustion.tscherry-picked from the original PR-010 branch (which had gone stale against the recovered main).What
open-sse/services/combo/__tests__/targetExhaustion.test.ts(13 tests) coveringapplyComboTargetExhaustionandComboExhaustionSetsbehavior.test:vitestrunner (check-test-discovery.mjs+vitest.mcp.config.ts).Validation (Hard Rule #18)
Impl (
targetExhaustion.ts) is present on the recovered main; this PR is test-only (no production logic changed).Co-authored-by: diegosouzapw diegosouza.pw@gmail.com