-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(backend,nextjs,clerk-sdk-node): Drop legacy return response in BAPI responses #2126
Conversation
🦋 Changeset detectedLatest commit: fa0aa4b The changes in this PR will be included in the next version bump. This PR includes changesets to release 6 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
if (!payload) { | ||
assert.false(true, 'This assertion should never fail. We need to check for payload to make TS happy.'); | ||
return; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assertResponse
/ assertErrorResponse
helpers were introduced to drop the !payload
check.
@@ -38,7 +38,12 @@ export const createClerkExpressRequireAuth = (createOpts: CreateClerkExpressMidd | |||
clerkClient, | |||
requestState, | |||
}); | |||
return handleInterstitialCase(res, requestState, interstitial); | |||
if (interstitial.errors) { | |||
// TODO(@dimkl): return interstitial errors ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nikosdouvlis WDYT about passing the errors of the interstitial request to the end-user?
We would probably remove this handling if we drop the remotePrivateInterstitial()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we remove remotePrivateIntestitial?
Also, what errors can be returned here? Im a bit skeptical to pass the errors to the user as that makes the error a public API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We haven't removed it yet, since we need to decide if we want to enforce the publishableKey in all our SDKs.
The local interstitial won't ever return an error but if the publishableKey is missing, fetching interstitial from BAPI will be triggered and that could result to the following errors (based on the Go backend):
- 401 due to missing secretKey or invalid Key
- 500
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rest LGTM
9be55f9
to
07edf5b
Compare
bbdb0cd
to
8647965
Compare
6b8d70b
to
92bbeb9
Compare
92bbeb9
to
53bef9c
Compare
28244ea
to
19cb42b
Compare
9dc8bfc
to
b5196ad
Compare
b5196ad
to
e50a198
Compare
@@ -38,7 +38,12 @@ export const createClerkExpressRequireAuth = (createOpts: CreateClerkExpressMidd | |||
clerkClient, | |||
requestState, | |||
}); | |||
return handleInterstitialCase(res, requestState, interstitial); | |||
if (interstitial.errors) { | |||
// TODO(@dimkl): return interstitial errors ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we remove remotePrivateIntestitial?
Also, what errors can be returned here? Im a bit skeptical to pass the errors to the user as that makes the error a public API
e50a198
to
fa0aa4b
Compare
Description
Currently the BAPI responses are in
{ data: unknown | null, errors: [] | null }
format but to avoid introducing a breaking change we convert those responses and return only thedata
part orthrow
an error if there areerrors
.With this PR we will drop the transformation and return the actual response. This is a breaking change since from now on
errors
prop in the return value to verify if the request succeededdata
prop in the return valueChecklist
npm test
runs as expected.npm run build
runs as expected.Type of change
Packages affected
@clerk/backend
@clerk/chrome-extension
@clerk/clerk-js
@clerk/clerk-expo
@clerk/fastify
gatsby-plugin-clerk
@clerk/localizations
@clerk/nextjs
@clerk/clerk-react
@clerk/remix
@clerk/clerk-sdk-node
@clerk/shared
@clerk/themes
@clerk/types
build/tooling/chore