Repository navigation
docs: remove stale Early Access note from MFA Flexible Factors doc - #1067
sanchitmehtagit wants to merge 2 commits into
Conversation
The MFA client API (MfaApiClient, MfaEnrollmentType, MfaVerificationType, MfaRequiredErrorPayload, etc.) has been GA since the old MFA APIs were deprecated (#932) and removed (#947), with active feature work since (DPoP support #992, getAuthenticators filtering fix #998). The Early Access banner predates that GA promotion and was never removed.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe MFA Flexible Factors documentation removes the Early Access callout for SDK support and the instruction to contact an Auth0 representative. ChangesMFA documentation
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~2 minutes Change: Other Suggested reviewers: Merge Risk: ⚪ Minimal · up to The update removes an obsolete availability notice without changing runtime behavior or build outputs. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
pmathew92
left a comment
There was a problem hiding this comment.
Are Flexible Factors Grant available in GA @gyaneshgouraw ?
pmathew92
left a comment
There was a problem hiding this comment.
Holding this PR till MFA goes GA
They are not yet GA, we are following up on this to get exact time frame when the feature goes GA. |
Summary
Removes a stale "Early Access — contact your Auth0 representative" banner from the MFA Flexible Factors Grant example doc. The MFA client API it warns about (
MfaApiClient,MfaEnrollmentType,MfaVerificationType,MfaRequiredErrorPayload,MfaRequirements, etc.) is GA and has been for a while:AuthenticationAPIClient#932, removed in breaking: removed the deprecated MFA APIs #947 (breaking) — the currentMfaApiClientsurface is the replacement, not a preview of it.getAuthenticatorsfiltering fix (fix: MFAClient getAuthenticators filtering based on Authenticator.type field #998),MfaRequiredErrorPayloadoptionality fix (#1272).com.auth0.android:auth0:4.0.1Maven artifact — every class/method this doc references (MfaApiClient.getAuthenticators/enroll/challenge/verify,MfaEnrollmentType.Otp,MfaVerificationType.Oob/.Otp,MfaException.MfaChallengeException/MfaVerifyException,TotpEnrollmentChallenge.barcodeUri) is compiled into the jar with matching signatures.The banner appears to be leftover copy from before the feature graduated to GA, and it survived the most recent edit to this file (
docs: correct MFA getAuthenticators snippet for enroll flow, 2026-08-28).Why this matters beyond docs accuracy
This file is the canonical MFA reference an AI coding-agent skill (
auth0/agent-skills) points at for Auth0.Android MFA integration tasks. Running two different LLMs (gpt-5.6-terravia Codex,claude-sonnet-5via Claude Code) against an eval that uses this exact doc showed the stale banner actively causing problems downstream:.aarand ranjavap; the other made ~20 separatecurlcalls fetching individual.ktsource files from GitHub, plus the CHANGELOG and a GitHub code-search query, to confirm each class/method actually shipped).Removing the stale banner removes the ambiguity that triggers this distrust-and-reverify behavior, for both AI agents and human readers who might otherwise assume the feature is gated when it isn't.
Test plan
javapagainstcom.auth0.android:auth0:4.0.1that all referenced classes/methods exist with matching signatures.Summary by CodeRabbit