All new code requires tests to ensure against regressions.
However, if your PR contains zero code changes, feel free to select the checkmark below to indicate so.
[X] Have you ran tests against this code?
[ ] This PR contains zero code changes.
Description of the Change
This PR begins the process of improving the error messages returned to users when something on the backend fails.
It's a grip of mine personally when something goes wrong and all you get is Server Error with no details on what can be done to fix it.
This PR aims to begin solving this problem. Since previously all returned error messages have always matched what was originally returned by the Atom API server, we are now taking the chance to improve on those. Since from Pulsar to PPM to the frontend website there don't seem to be any special checks for the exact string of error messages, so this move seems safe to consider. Even then, in case there are third party tools that check the exact strings returned, those will still work without issue.
How this is done, is by not only returning the message that most users are familiar with, the backend will also return details (where supported) to provide deeper insight into what has gone wrong during the request. This new handling has first been added explicitly to the postPackagesVersion() function that handles the logic when a new package version is being published. As this seems to be the biggest current focus, it can help Pulsar Developers more quickly find the offending code when we have exact strings to use, and can help users to aid during troubleshooting to see what has gone wrong.
The eventual goal will be to have all error messages returned this way once possible.
Requirements
Filling out the template is required.
All new code requires tests to ensure against regressions.
[X] Have you ran tests against this code?
[ ] This PR contains zero code changes.
Description of the Change
This PR begins the process of improving the error messages returned to users when something on the backend fails.
It's a grip of mine personally when something goes wrong and all you get is
Server Errorwith no details on what can be done to fix it.This PR aims to begin solving this problem. Since previously all returned error messages have always matched what was originally returned by the Atom API server, we are now taking the chance to improve on those. Since from Pulsar to PPM to the frontend website there don't seem to be any special checks for the exact string of error messages, so this move seems safe to consider. Even then, in case there are third party tools that check the exact strings returned, those will still work without issue.
How this is done, is by not only returning the
messagethat most users are familiar with, the backend will also returndetails(where supported) to provide deeper insight into what has gone wrong during the request. This new handling has first been added explicitly to thepostPackagesVersion()function that handles the logic when a new package version is being published. As this seems to be the biggest current focus, it can help Pulsar Developers more quickly find the offending code when we have exact strings to use, and can help users to aid during troubleshooting to see what has gone wrong.The eventual goal will be to have all error messages returned this way once possible.