refactor(relay): route auth through admissions - #3800
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (4)
💤 Files with no reviewable changes (2)
Included review availability: Your plan provides up to 4 included reviews per hour; 1 remains after this review. WalkthroughThe relay auth implementation replaces mode-based admission handling with queued admissions and spawned Priority: ⬇️ Low 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Co-Authored-By: GPT-5 <noreply@openai.com>
Co-Authored-By: GPT-5 <noreply@openai.com>
Co-Authored-By: GPT-5 <noreply@openai.com>
96ae66e to
9a887e1
Compare
|
No issues found. |


Problem
Auth::admithad separate server, public, embedded, and refusal paths, so admission behavior could diverge by configuration.Approach
Authclone send anAdmissionand await its answer.Error::Refused, matching the auth-server path.Impact
auth::Config::initandAuth::refusenow require an active Tokio runtime. The auth module is unpublished.Alternatives
Keeping direct
Modedispatch would preserve multiple admission implementations and the duplication this quest removes.Testing
just checkjust rs test -p moq-relay: 216 passed, 2 skippedFollow-ups
None.
(written by GPT-5)