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.
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
Log errors and exit on authentication issues on Hubot plugin initialization #168
Log errors and exit on authentication issues on Hubot plugin initialization #168
Changes from 38 commits
8f7c74e
c2770bb
6613a3d
fe44e13
c3b451f
d44be18
3bf6fe2
51b0262
969c084
98cf5f2
233915c
0cf0e26
28d2e4c
76e7179
f588845
8518e92
52a4d0f
862a331
b112859
63abae1
97f2ef9
b07c28f
189b2d0
2ccc85e
e6c5e01
df5a0db
1765c47
7605f3c
0dcba8a
f81eca6
965ffb1
95a4434
a5311e9
c39ba0f
6a39dfb
9ac9aa7
9903e19
5c86bfa
6165f1e
6d11ae2
de756aa
59147a6
47639de
954ec13
1432afd
e7e9d93
f346581
82b8fe6
27523a0
7ee397f
0b75e5b
68d3b9d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I found that second param
res
is only used inrobot.error
Hubot handler for uncaught exceptions.Does it make sense to move entire
logErrorAndExit
code intorobot.error
handler itself?And from the code where we want to exit just
throw err
as it was before. Looks better in the context of https://stackoverflow.com/a/40321400/4533625 (case 3) discussion.It will be caught by
robot.error
then.By throwing when we want to end an app (which will then call
robot.error
) I think allows any other bubbled up tasks to actually finish in a more safe way. It'll also stick with the previous code logic primitives.@blag What do you think?
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.
I considered this and ultimately decided against it. We use
logErrorAndExit
in one more place than just the Hubot error callback, and I suspect that we will expand the use of it in further commits.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.
@jinpingh What do you think?
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.
Since we changed how
st2chatops
should be behaviors if something went wrong from initial design, before I understand the goal for this PR, will not change it.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.
I'm actually talking about reverting initial design where we previously
throw
'ed error as a way to complete hubot execution.In our case
robot.error
handler will automatically catch those exceptions as unhandled and then callstop
.Here is the diff:
By technical reasons I think that raising
robot.error
handler which then callsstop()
viathrow
instead oflogErrorAndExit
function would align better with the existing shutdown mechanics.Add here cases when users want to re-use
hubot-stackstorm
module and so adding ability to catch errors and re-definerobot.error
on their side would make sense.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.
That isn't quite how the new code works.
Calling
robot.error
simply adds a callback function to the callback chain for theerror
event. See this code in Hubot for more.If our users want to change or remove any of the error callbacks, they can still do so, they just have to manipulate
robot.errorHandlers
themselves. It's not as simple as assigning a function torobot.onerror
anymore.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.
Making the hubot error handler an unnamed lambda function, and then simply re-
throw()
ing exceptions is fine.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.
What if by refactoring reasons backend returned
401
HTTP code andAuthorization Required
(notUnauthorized
) as a message ?I think
||
would be more appropriate as a logical operator here.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.
It doesn't make sense to handle an unauthorized error differently than another non-connection error, so I had it always handle it this way. The current code looks like (
function loadCommands
):This allows the
loadCommands
promise to log the error before it rejects, and then rejects are either ignored (function start
):or the rejection is simply passed up the stack (
function start
):and handled elsewhere (init code):