[diegosouzapw]

Summary

• Describe the user-facing or operational change.

Related Issues

• Closes #
• Related to #

Validation

• npm run lint
• npm run test:unit
• npm run test:coverage
• Coverage is still >= 60% for statements, lines, functions, and branches
• SonarQube PR analysis is green or any remaining issues are explicitly documented below

Tests Added Or Updated

• List every changed or added automated test file.
• If no production code changed, state that here.

Coverage Notes

• If this PR changes src/, open-sse/, electron/, or bin/, explain which tests cover the change.
• If coverage moved down in any touched file, explain why and what follow-up task will recover it.

Reviewer Notes

• Call out any risky areas, migrations, feature flags, or manual validation that reviewers should know about.

[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 introduces a client-facing self-service status endpoint (GET /api/v1/me/status) and corresponding dashboard controls to allow API keys to inspect their own USD usage, token totals, and shared upstream account quotas (with explicit opt-in). It hardens the existing budget endpoints with handler-level management auth, adds a database migration to backfill self-service scopes, and optimizes memory usage across the codebase by implementing strict caps, sweeps, and LRU eviction on various in-memory caches, registries, and statement caches. Review feedback highlighted a critical correctness bug in the UNION ALL analytics query where aggregated rows from daily_usage_summary would be incorrectly counted as single requests. Additionally, the reviewer recommended using ByteLengthQueuingStrategy to ensure the highWaterMark on stream transforms is byte-based rather than chunk-based, and suggested adding defensive optional chaining checks when resolving provider limits to prevent runtime TypeErrors.

[gemini-code-assist]

There is a major correctness bug in the UNION ALL design of unifiedSource.

daily_usage_summary is an aggregated table where each row represents multiple requests (stored in total_requests). However, in unifiedSource, each row from daily_usage_summary is selected as a single row with hardcoded values like 1 as success.

When the analytics queries (which are not modified in this diff but are executed on unifiedSource) perform COUNT(*) or COUNT(1) to calculate the total number of requests, or use SUM(CASE WHEN success = 1 THEN 1 ELSE 0 END) to calculate successful requests, they will count each aggregated row from daily_usage_summary as exactly one request. This will result in a massive undercount of historical requests (e.g., a day with 10,000 requests will be counted as 1 request).

To fix this, the database queries should be refactored to aggregate both sources separately and then merge the results in JavaScript, or the schema/queries must use a request_count column (e.g., 1 AS request_count for usage_history and total_requests AS request_count for daily_usage_summary) and sum that column instead of using COUNT(*).

[gemini-code-assist]

The high water mark of 16384 is specified here without a size function or a ByteLengthQueuingStrategy. In the Web Streams API, the default queuing strategy is count-based (where each chunk counts as 1). Therefore, highWaterMark: 16384 allows buffering up to 16,384 individual chunks (e.g., Uint8Array objects) rather than 16,384 bytes.

If the intention was to limit the buffer to 16 KB (as indicated in the unit tests), you should use ByteLengthQueuingStrategy to ensure the limit is byte-based instead of chunk-based. Otherwise, buffering up to 16,384 chunks per stream could lead to significant memory overhead under high concurrency or slow client connections.

Suggested change

	{ highWaterMark: 16384 },
	{ highWaterMark: 16384 }
	new ByteLengthQueuingStrategy({ highWaterMark: 16384 }),
	new ByteLengthQueuingStrategy({ highWaterMark: 16384 })

[gemini-code-assist]

Add defensive checks on result and result.usage before accessing usage.quotas. If fetchAndPersistProviderLimits returns an unexpected structure or undefined, accessing result.usage or usage.quotas will throw a TypeError.

Using optional chaining (result?.usage and usage?.quotas) prevents potential runtime exceptions and handles unexpected API structures gracefully.

Suggested change

	const result = await deps.fetchAndPersistProviderLimits(allowedConnections[0], "manual");
	const usage = result.usage as JsonRecord;
	const quotas =
	usage.quotas && typeof usage.quotas === "object" && !Array.isArray(usage.quotas)
	? (usage.quotas as JsonRecord)
	: null;
	const result = await deps.fetchAndPersistProviderLimits(allowedConnections[0], "manual");
	const usage = result?.usage as JsonRecord | undefined;
	const quotas =
	usage?.quotas && typeof usage.quotas === "object" && !Array.isArray(usage.quotas)
	? (usage.quotas as JsonRecord)
	: null;

[github-actions]

CI Coverage Report

• Coverage job: skipped
• PR test policy: failure

Coverage artifact was not available for this run.

PR Test Policy

This PR changes production code in src/, open-sse/, electron/, or bin/ without accompanying automated tests.