Code Review — #1616 fix(email): wire EmailSendRequest.provider fallback + exact pre-scan budget

Summary

Solid, tightly-scoped follow-up — Approve with suggestions. All three production changes are correct and the root-cause store.list_connections() fix is the right call: making enumeration registry-driven (filter spec.type == "oauth_pkce") is consistent with the existing pattern at api.py:569 and fixes every generic consumer at once rather than patching one caller. Fail-loud behavior is preserved throughout — an invalid request.provider still 400s/503s, no silent fallback. The one thing worth your attention before merge: the new pre-scan budget regression test passes identically with and without the fix, so it doesn't actually guard the regression it names.

Issues

🟡 Budget-guard regression test doesn't exercise the fix (tests/unit/agents/email/test_multi_inbox_triage.py:244)

test_pre_scan_budget_counts_actual_returned_not_per_backend_cap uses exactly two backends and asks for 4 (per_backend = 4 // 2 = 2). The early-exit if scanned >= max_messages: break sits at the top of the loop, so it can only skip a backend that comes after the one that crossed the budget. With two backends, the only skippable one is the second/last — and to skip it the old code would need scanned >= 4 after google. The old scanned += per_backend adds just 2 there (2 < 4), so microsoft runs regardless. Result: the assertion mailboxes == {"google","microsoft"} is green on both the pre-fix (+= per_backend) and post-fix (+= actual) code — it doesn't fail-first.

The overcount can only skip a backend with ≥3 backends (or any setup where the cumulative over-count crosses max_messages before a later backend is reached). Suggest a three-backend scenario where the first two are under-filled, e.g. backends a=["a1"], b=["b1"], c=["c1","c2","c3"] with pre_scan_inbox(6) (per_backend = 2): under the old cap, a+b push scanned to 4 and a third would be at the cutoff sooner — pick counts so the old count reaches max_messages before c but the actual count does not, then assert c's mailbox is present. The production fix itself is correct; only the test needs strengthening so a future regression here is caught.

🟢 WHY comment runs a touch long (hub/agents/python/email/gaia_agent_email/agent.py:521) — the four-line block explains the rationale well, but CLAUDE.md leans toward one-line WHY comments. Optional trim; the content is accurate so not worth blocking on.

Strengths

• Root-cause over workaround. Driving enumeration off REGISTRY.all() rather than extending a hardcoded tuple means the next oauth_pkce provider is picked up with zero edits here, and the function-local import (mirroring api._require_mcp_server_for_activation) keeps the module free of a registry-level dependency. The test_list_connections_finds_both_providers assertion that mcp-git is excluded nicely pins the oauth_pkce-only contract.
• Provider-precedence tests are thorough. The three TestSendRequestProviderFallback cases cover the real matrix — unbound→request.provider routes, bound-token wins over request.provider, and unbound+none+both-connected still 400s — and the spy asserts no send leaks through the ambiguity guard (calls == []).
• Secret-leak assertion included. test_microsoft_connection_visible_to_generic_api checks refresh_token not in conn, so the Microsoft-visibility fix can't silently start leaking token material through get_connection.
• Updated EmailSendRequest.provider description and the send_email precedence comment now match the wired behavior exactly — docstring and code agree.

Verdict

Approve with suggestions. No correctness or security blockers — the production fixes are sound and well-tested where it counts. Strengthening the one budget-guard test to a ≥3-backend scenario (so it fails on the pre-fix code) is the only thing I'd ask for, and it's a test-only change.

Addressed in dfe1b1d6 (test-only).

You're right the prior test was green on both the old (scanned += per_backend) and new (scanned += actual) code, so it didn't fail-first. But the suggested 3-backend variant can't expose it either: while max_messages ≥ n_backends, the over-count can never trip the early-exit, because (N-1)·⌊max/N⌋ < max always holds — so no later backend is ever skipped regardless of the counter.

The behavior only diverges when max_messages < n_backends: then per_backend floors to 1 and an under-filled earlier backend lets the old over-count cross the budget early. The new test hits exactly that, with GAIA's real two backends:

• google inbox empty (0 messages), microsoft has 1, pre_scan(max_messages=1) → per_backend = max(1, 1//2) = 1.
• OLD += per_backend: empty google bumps scanned to 1 → guard trips → microsoft skipped.
• NEW += actual: google returns 0 → scanned stays 0 → microsoft scanned.
• Asserts microsoft is present. Verified RED on the reverted pre-fix code (assert 'microsoft' in set() → 1 failed), GREEN on the fix.

Renamed to test_pre_scan_under_budget_backend_not_skipped_when_earlier_backend_underfills. Also trimmed the 4-line WHY comment at agent.py to one line per the 🟢 note.