-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(core): Allow to pass onSuccess
to handleCallbackErrors
#17679
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
Conversation
size-limit report 📦
|
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
Noticed while working on #17679, we incorrectly changed the `this` context here (which is also why TS complained). I rewrote this to a proxy which should keep the context properly.
0a7f229
to
1222e4e
Compare
…nction` (#17680) Noticed while working on #17679, this was actually incorrect here. `handleCallbackErrors` does not actually do anything, you need to still call the function you want to call in the error case! Actually we can just drop this as this error is handled by some other handler anyhow, I think, according to the tests!
1222e4e
to
0fbf6eb
Compare
I've seen a few places where we are wrapping things that could be sync or async, and we want to do something with the return value. By adding an onSuccess handler to `handelCallbackErrors` we can handle this more generically in the future. revert and fix vendor type in better awaited??
0fbf6eb
to
0e61da1
Compare
I've seen a few places where we are wrapping things that could be sync or async, and we want to do something with the return value. By adding an onSuccess handler to
handelCallbackErrors
we can handle this more generically in the future:While scanning a bit for places where we could already use this, I also found two bugs around this, opened separate PRs for them:
HandleDocumentRequestFunction
#17680this
context for vercel AI instrumentation #17681