Second live-reported invite bug from Jay (companion to #2064). Repro on the Pi (beta.42): open Invite external agent, select scopes, press Mint invite. Server logs show POST /api/projects/{id}/invites returned 200 OK and the invite was created, but the dialog simply closed - no URL, no PIN, nothing. The one-time PIN is unrecoverable afterward, so the created invite is orphaned (it still counts toward the 6-pending cap).
The success path EXISTS in the component (InviteAgentDialog.tsx:168 builds the instruction string from result.invite_id + result.pin), so the mint handler is either throwing after the fetch resolves (response-shape mismatch swallowed by a catch that closes the dialog - pitfall 8) or a state update races the close. Note the mint response shape is flat {invite_id, pin, expires_ts, scopes, approval_mode, check_interval_secs} - verify the handler is not expecting a nested record (the #2045 store changes altered the record dict; check whether the route response changed with it).
Fix: (1) find and remove the silent failure - on any post-mint render error the dialog must show the error, never close; (2) show the success view with URL + PIN and a copy button; (3) since the PIN is shown once, add a test asserting the success view renders from the FLAT response shape; (4) consider surfacing newly-minted-but-unviewed invites in Pending invites with a cancel action so orphans are recoverable.
Live evidence: Pi journal 17:01:18 POST 200 followed by GET 200, dialog closed with no bundle shown. Jay was unblocked via a direct API mint.
Second live-reported invite bug from Jay (companion to #2064). Repro on the Pi (beta.42): open Invite external agent, select scopes, press Mint invite. Server logs show POST /api/projects/{id}/invites returned 200 OK and the invite was created, but the dialog simply closed - no URL, no PIN, nothing. The one-time PIN is unrecoverable afterward, so the created invite is orphaned (it still counts toward the 6-pending cap).
The success path EXISTS in the component (InviteAgentDialog.tsx:168 builds the instruction string from result.invite_id + result.pin), so the mint handler is either throwing after the fetch resolves (response-shape mismatch swallowed by a catch that closes the dialog - pitfall 8) or a state update races the close. Note the mint response shape is flat {invite_id, pin, expires_ts, scopes, approval_mode, check_interval_secs} - verify the handler is not expecting a nested record (the #2045 store changes altered the record dict; check whether the route response changed with it).
Fix: (1) find and remove the silent failure - on any post-mint render error the dialog must show the error, never close; (2) show the success view with URL + PIN and a copy button; (3) since the PIN is shown once, add a test asserting the success view renders from the FLAT response shape; (4) consider surfacing newly-minted-but-unviewed invites in Pending invites with a cancel action so orphans are recoverable.
Live evidence: Pi journal 17:01:18 POST 200 followed by GET 200, dialog closed with no bundle shown. Jay was unblocked via a direct API mint.