mconley

3752: Publicize a list of taken WebAPIError error code blocks from public extensions

mconley 
What version are you running?
N/A

What's the URL of the page this enhancement relates to, if any?
N/A

Describe the enhancement and the motivation for it.

We're developing some extensions with WebAPIResource's, and we're developing new WebAPIError's for these endpoints. We're not sure what we're supposed to be choosing for the WebAPIError error codes (not the HTTP status codes). They seem to be arbitrarily chosen. At this point, we just know we should probably avoid colliding with any error codes from Review Board, Djblets or any of our other extensions.

I can see this becoming more of an issue as more and more extensions become available and introduce new WebAPIErrors. I'm really not sure how best (or how necessary it is) to avoid collisions with other WebAPIError status codes. One thing I was thinking about was having some code in the package store that scans Review Board extensions for WebAPIErrors and collects the codes that are being used, and provide a list of those error codes. That way, a developer could choose wisely and avoid collision.


What operating system are you using? What browser?
N/A

Please provide any additional information below.
chipx86
#1 chipx86 
What I'd like to do for API version 3 is to move away from error codes to error IDs (strings). That would solve this problem.

Right now, yeah, it's an issue. I'd say start at 1000, since we're not going up that high. If you collide with a code from another extension, well, those codes are going to be extension-dependent, so the clients just need to know which they're interacting with, I suppose.

We should probably officially say 1000+ are reserved for per-extension error codes.