Use Axios's toJSON method to make shorter errors (#632)
#662
Conversation
* Use Axios's `toJSON` method to make shorter errors On an example erroring docassemble server (for example, this server returning a [502 to a delete project](https://github.com/SuffolkLITLab/docassemble-EFSPIntegration/actions/runs/3641406524/jobs/6147303425)), the entire axios error will print, which is that case in 1.8k lines, most of it being garbage. Axios has a `toJSON()` method on errors that should reduce length of the errors being shown, as it will not print the most annoying parts of the long errors, like the internal Axios socket objects Still need to test, as it's difficult to get a server to 502 on demand. Fix #605. * Actually fail when we log the errors * Move `toJSON()` calls to docassemble_api_REST * Add better comment to `process.exitCode` Co-authored-by: plocket <52798256+plocket@users.noreply.github.com>
| <!-- ## [Unreleased] --> | ||
| ## [Unreleased] | ||
| ### Changed | ||
| - Shorten Axios errors to make them more readable (https://github.com/SuffolkLITLab/ALKiln/pull/632) |
There was a problem hiding this comment.
I think the issue number isn't what you intended?
| - Shorten Axios errors to make them more readable (https://github.com/SuffolkLITLab/ALKiln/pull/632) | |
| - Shorten Axios errors to make them more readable (https://github.com/SuffolkLITLab/ALKiln/pull/605) |
There was a problem hiding this comment.
I also liked the list of changes in the comment so I put them here, but if you don't want to include that, that's fine. Just an alternative version.
| - Shorten Axios errors to make them more readable (https://github.com/SuffolkLITLab/ALKiln/pull/632) | |
| - Shorten Axios errors to make them more readable (https://github.com/SuffolkLITLab/ALKiln/pull/605) | |
| - Actually fail when we log the errors | |
| - Move `toJSON()` calls to docassemble_api_REST | |
| - Add better comment to `process.exitCode` |
There was a problem hiding this comment.
I do intentionally link to the PR when I fix things. Issues usually have a lot of extra discussion that don't get implemented, and the issue is still linked to from the PR, usually in the first comment. I've found it's a lot easier to find the issue fixed from a PR than finding the PR from the issue.
I normally would be fine with adding more details to the changelog, but those specific commit comments are very internal, and don't make sense outside the context of the choices made in the PR ("move toJSON calls" move them from where? from a different file they were in earlier in the PR. From the changelog comment, it looks like those toJSON calls were around before that release, but they weren't).
There was a problem hiding this comment.
Those make some sense. I'm good with whatever you choose.
|
Also, do you think this also handles #550 sufficiently? |
|
TBH, I don't think it addresses #550, at least not the first part. I'll mark the second part as being done there. |
Accidentally merged #632 into
releases/v4instead ofv4(the PR pre-datedv4as the default branch), so this process is backwards; but here's the changes cherry-picked fromreleases/v4.toJSONmethod to make shorter errorsOn an example erroring docassemble server (for example, this server returning a 502 to a delete project), the entire axios error will print, which is that case in 1.8k lines, most of it being garbage.
Axios has a
toJSON()method on errors that should reduce length of the errors being shown, as it will not print the most annoying parts of the long errors, like the internal Axios socket objectsStill need to test, as it's difficult to get a server to 502 on demand.
Fix #605.
toJSON()calls to docassemble_api_RESTprocess.exitCode