fix(android): derive Voice readiness from Gateway catalog#98269
Conversation
|
Codex review: needs maintainer review before merge. Reviewed July 3, 2026, 2:29 AM ET / 06:29 UTC. Summary PR surface: Source +80, Tests +345, Docs 0, Other +682. Total +1107 across 16 files. Reproducibility: yes. The linked issue describes a mixed Gateway catalog state, current main source still uses generic/static Android readiness, and inspected before/after emulator screenshots show the false-ready state versus the candidate behavior. Review metrics: 2 noteworthy metrics.
Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land after a maintainer accepts the upgrade-visible catalog-gated Android routing and exact-head CI is terminal green, while keeping the adjacent cold-provider loading work in #97170 separate unless maintainers intentionally combine them. Do we have a high-confidence way to reproduce the issue? Yes. The linked issue describes a mixed Gateway catalog state, current main source still uses generic/static Android readiness, and inspected before/after emulator screenshots show the false-ready state versus the candidate behavior. Is this the best way to solve the issue? Yes, with maintainer acceptance. Gateway-owned readiness plus one Android closed readiness model is the maintainable fix; an Android-owned alias table would duplicate provider policy, and the cold-provider loading concern remains separate in #97170. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 4e6933c84f18. Label changesLabel justifications:
Evidence reviewedPR surface: Source +80, Tests +345, Docs 0, Other +682. Total +1107 across 16 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
2f48b09 to
eb2d810
Compare
c6d2aef to
159c1c6
Compare
|
Real Android emulator proof for the Voice/Talk readiness changes is attached here and mirrored in the PR body.
Voice tab readiness and persistent setup issue panel: Voice Setup using the same Gateway catalog-derived rows: Voice to Voice Setup flow proof: |
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8c98b68daa
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // Provider priority belongs to the runtime resolver; catalog consumers must not infer it from row order. | ||
| try { | ||
| return { | ||
| activeProvider: configuredProvider ?? resolveAutomaticProvider(), |
There was a problem hiding this comment.
Validate explicitly selected Talk providers before marking ready
When talk.realtime.provider or the voice-call streaming provider is explicitly set, this short-circuits the runtime resolver and returns ready: true without checking credentials. In the common setup flow where a provider is selected but its API key is missing, the row below still has configured: false, but Android treats the group ready flag as authoritative and enables Talk/Dictation instead of routing to setup; the actual session resolver would reject the same config as not configured. Call the resolver for explicit selections too, and only use the configured id as the active provider after that succeeds.
Useful? React with 👍 / 👎.
Co-authored-by: Colin <[email protected]>
|
Merged via squash.
|



Closes #98268
AI-assisted: yes. Sanitized transcript logs were not included.
What Problem This Solves
Android Voice treated a connected Gateway as proof that both Realtime Talk and Dictation were ready. That produced false-ready UI when one selected provider lacked credentials and could not represent mixed provider state.
Why This Change Was Made
Gateway
talk.catalognow additively exposes provider registry aliases plus an authoritative group readiness bit, and resolves every row through the canonical config owner used by runtime calls. Android consumes that response through one closed readiness model shared by Voice, Voice Setup, permission continuations, and Talk mode.The rewrite removes the original PR's Android-owned alias table and parallel readiness flags. Unknown catalog state remains non-blocking so an older Gateway or newer provider stays authoritative; confirmed missing setup routes only the affected mode to the existing settings flow. Realtime close failures also retain their specific status instead of being overwritten by a generic phase label.
User Impact
Realtime Talk and Dictation can now show different, accurate readiness. For example, Google Live Voice may need setup while OpenAI Realtime Transcription is ready, and setup actions block only the affected mode.
Evidence
161b585d5a4b661b24fd6c75e50e4a7715705117.The live matrix used an intentionally non-production OpenAI credential. It proves catalog ownership, alias canonicalization, device pairing, Android routing, and mixed-state rendering; it does not claim a billed provider transcription turn. No physical Android device was available.