-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Remove try/catch for short url so the appropriate errors will be propagated to the UI #13004
Remove try/catch for short url so the appropriate errors will be propagated to the UI #13004
Conversation
c72a288
to
b62b879
Compare
I'm concerned with the potential BWC impact of a change like this. Also, since this is going to lead to more error responses I took a look at src/server/http/short_url_error.js, which I think needs to be updated to just wrap the error object rather than replace it with new Boom errors. At least the function is checking if the error is a Boom error first, but replacing the entire function with PS: unlike the name suggests, |
Can you explain a bit more about the BWC concerns? As far as I can tell, any error previously would have showed up with the '/' error, but now the error will be different. You think people will be relying on the '/' error? I def don't want to cause any harm, but it does seem weird that errors are swallowed and replaced with a different, random error. If this gets in to 6.0, we don't have to be as concerned with BWC... ? |
…original error details.
Yeah, that's the only thing I was concerned with. That said, I think as long as what was once an error is still an error I'm good with it. And yeah, if we get this into 6.0 then there really aren't any BWC concerns. |
…how-short-url-errors
…how-short-url-errors
Failing on:
Will merge again with master and push |
…how-short-url-errors
Sorry @stacey-gammon, fixed that in #13021 |
jenkins, test this |
…how-short-url-errors
Hmm, thought I merged with the latest to grab the fix. Failing on:
|
Confirmed i'm on the latest version. jenkins, test this |
…how-short-url-errors
tests now passing, ready for a final look. |
…how-short-url-errors
src/server/http/short_url_error.js
Outdated
if (err.status === 404) return Boom.notFound(); | ||
return Boom.badImplementation(); | ||
export function handleShortUrlError(error) { | ||
if (!error.isBoom && !(error instanceof Error)) { |
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 really should not support non-errors here. Pretty sure this was spurred by the tests failing because they aren't sending real errors, which means that this code isn't actually testing what would happen in production with this condition. I think this check should go, we should always use Boom.wrap()
and the tests should use real error objects.
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 can do that, I was just worried about changing implementation details, not knowing if I would create a subtle bug somewhere.
jenkins, test this |
…how-short-url-errors
jenkins, test it |
a509e00
to
b7870ab
Compare
Failed on:
Looks like a flaky test. Will sync with master and try again. |
…how-short-url-errors
it(`should handle ${err.status} errors`, function () { | ||
expect(_.get(handleShortUrlError(err), 'output.statusCode')).to.be(err.status); | ||
it(`should handle ${err.status || err.statusCode} errors`, function () { | ||
expect(_.get(handleShortUrlError(err), 'output.statusCode')).to.be(err.status || err.statusCode); |
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.
The first error in uncaughtErrors
is going to have a status and statusCode of undefined, right? Isn't that I think these three tests should just be written separately, rather than implementing unnecessary looping/conditional checking
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 split out the status and statusCode checks, but the errors in those two test loops should always have either status or statusCode defined. Only uncaughtErrors test has a case when they are both undefined.
…agated to the UI (elastic#13004) * Remove try/catch for short url so the appropriate errors will be propagated to the UI * Simply ensure the error is a Boom error by wrapping it, but keep the original error details. * Boom.wrap can't handle non Error instances, as exist in some of the tests. * Only support Error objects, and check both status and statusCode * fix test * Fix test errors for reals this time * Break out status and statusCode short url error tests
…agated to the UI (#13004) (#13179) * Remove try/catch for short url so the appropriate errors will be propagated to the UI * Simply ensure the error is a Boom error by wrapping it, but keep the original error details. * Boom.wrap can't handle non Error instances, as exist in some of the tests. * Only support Error objects, and check both status and statusCode * fix test * Fix test errors for reals this time * Break out status and statusCode short url error tests
Previously, any error with a short url, e.g. looking for one that didn't exist, or encountering an auth exception, would all result in the same ambiguous error:
With this change, the right "not found" Boom error will be sent to the user, as should auth exceptions (that was hard to test since you can't log in to kibana without read permissions, but theoretically it should be propagated as well).
Fixes #10456
cc @spalger - you commented on the original issue so tagging you if you want to take a look.