-
Notifications
You must be signed in to change notification settings - Fork 399
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
Fix #859 Improve the way to handle authorize fn errors in built-in receivers #891
Conversation
Codecov Report
@@ Coverage Diff @@
## main #891 +/- ##
==========================================
- Coverage 71.01% 65.48% -5.53%
==========================================
Files 13 13
Lines 1235 1217 -18
Branches 362 359 -3
==========================================
- Hits 877 797 -80
- Misses 288 351 +63
+ Partials 70 69 -1
Continue to review full report at Codecov.
|
As we are aiming to release v3.4.0 within a few days and this pull request needs more time, let me move this one to v3.5 milestone. |
6d8e685
to
11f7c9e
Compare
I wanted to write some unit tests for this change but I found that it's not that simple and it may take longer than I thought. For this reason, I did some manual tests with example apps using Example apps that I used for testing: import { App } from '@slack/bolt';
const app = new App({
signingSecret: process.env.SLACK_SIGNING_SECRET,
authorize: async (_) => { throw new Error("Failed!"); }
});
(async () => {
await app.start(Number(process.env.PORT) || 3000);
console.log('⚡️ Bolt app is running!');
})(); import { App, ExpressReceiver } from '@slack/bolt';
const app = new App({
receiver: new ExpressReceiver({ signingSecret: process.env.SLACK_SIGNING_SECRET!! }),
authorize: async (_) => { throw new Error("Failed!"); }
}); |
This one is waiting for reviews |
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.
LGTM!
…lt-in receivers
11f7c9e
to
d641204
Compare
resolved conflicts |
Summary
This pull request closes #859 by improving the error handling of
authorize
function failures. As described here, the current implementation returns 500 Internal Server Error in the case and displays the following warn/error logs.As we recommend throwing an exception if there is no valid installation data in
fetchInstallation
method, this pattern should be handled as a normal case, not an internal server error.This pull request fixes #364 too.
Requirements (place an
x
in each[ ]
)