fix(oauth): read the OAuth error code from a nested details object - #121
Merged
Conversation
getOAuthErrorCode only looked at a top-level `code`, which is where the auth API puts it. That made the SDK depend on the API's exact top-level error shape: any proxy that normalized the body and moved the siblings of `error` under `details` silently dropped the code, so the UI fell back to generic messaging instead of the user-actionable message. seamless-auth-server#124 hit this and had to forward auth API error bodies verbatim to work around it, which now constrains error handling there. Accept both locations, top level first, and keep the allowlist unchanged so an unrecognized code in either place still returns undefined. Closes #120
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #120
getOAuthErrorCoderead the OAuth failure code from a top-levelcodekey on the parsed error body, which is where the auth API puts it ({ error, message?, code? }, seesrc/schemas/oauth.responses.tsinseamless-auth-api). That hard-coupled the SDK to the API's exact top-level shape: any intermediary that normalized the error body broke OAuth messaging silently, becausecoderead asundefinedand the UI fell back to a generic error instead of the user-actionable message.That already happened in practice. fells-code/seamless-auth-server#124 had to forward auth API error bodies verbatim specifically because normalizing them (moving the siblings of
errorunder adetailsobject) broke this function, and that constraint now blocks cleanup work in that repo.Change
getOAuthErrorCodenow accepts the code in either location: the top level first, exactly as before, then a nesteddetailsobject when the top level does not carry one. Everything else is unchanged, including the public signature and the allowlist, so an unrecognized code in either place still returnsundefinedand callers keep their generic messaging.Tests
Added coverage in
tests/errors.test.tsfor each known code nested underdetails, top level winning when both are present, an unrecognized code in each location,detailspresent without a code, a null/undefined/non-object body, and a non-objectdetails.Checks
npm test -- --runInBand(31 suites, 276 tests passing),npm run typecheck,npm run lint,npm run format:check, andnpm run buildall pass locally.Patch changeset included since this changes user-facing behavior for adopters behind a normalizing proxy.