Repository navigation
id(directory): bound aggregate pending email-code state and issuance cost #5749
Description
Problem
Pending email verification state has expiry but no aggregate size bound. In pkgs/id/src/directory_auth.rs:149-161 and 167-188, issue_code sweeps expired entries and then inserts the new address; the map has no hard capacity, and each issuance scans it. Authenticated AddEmail accepts caller-supplied addresses (pkgs/id/src/directory_view.rs:1238-1257). Repeated requests for unique addresses can grow memory without bound and make each later issuance more expensive.
Closed #1732 addressed retention of expired codes but does not bound many unexpired entries.
Required behavior
Introduce an explicit global and/or per-principal cap for pending email-code state. Reject or replace excess entries deterministically, preserve normal resend and expiry semantics, and make sure one principal cannot starve unrelated users. Keep verification and one-time-use behavior unchanged.
Acceptance criteria
- Tests fill the pending-code capacity and verify deterministic rejection or eviction without exceeding the bound.
- If per-principal isolation is the chosen policy, a test proves one principal cannot consume every slot.
- Expired entries are still reclaimed, and valid codes still verify exactly once.
- Issuance cost stays bounded as the number of distinct pending addresses grows.
Activity
developing-today commentedon Nov 5, 2026
CODE-1438
developing-today commentedon Nov 5, 2026
agent-note:v1
task: 10161
lane: code-j
state: handed_off
execution_lane: opencode
note: Claimed by lane code-j (attempt 3/6, repeat handoff); issue #5749 verified OPEN with no hard-stop labels via developing.today app token (gh user token rate-limited). Handed off to opencode claimant to launch the bound session; parking 1800s pending claimant launch.
dezren39 commentedon Nov 5, 2026
🤖 Agent note · handed off