Skip to content

Return a more specific http status code on conflict.#10207

Open
jmcarp wants to merge 1 commit intomainfrom
jmcarp/conflict
Open

Return a more specific http status code on conflict.#10207
jmcarp wants to merge 1 commit intomainfrom
jmcarp/conflict

Conversation

@jmcarp
Copy link
Copy Markdown
Contributor

@jmcarp jmcarp commented Apr 2, 2026

Just a nit I noticed while working on something else. Semantically, ObjectAlreadyExists maps to an http 409 and not a 400.

@david-crespo
Copy link
Copy Markdown
Contributor

This is going to break a whole lot of tests.

Copy link
Copy Markdown
Contributor

@sudomateo sudomateo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually, generic HTTP status codes are used as a security measure to prevent clients from enumerating information about API objects. Since we already return ObjectAlreadyExists text perhaps that's a moot point and this change makes sense as-is.

@jmcarp jmcarp force-pushed the jmcarp/conflict branch 2 times, most recently from d0c5fc8 to b77feb2 Compare April 2, 2026 02:17
@davepacheco
Copy link
Copy Markdown
Collaborator

Reference: https://github.com/oxidecomputer/omicron/blob/main/docs/http-status-codes.adoc#client-errors

This is changeable but it does seem like a breaking API change.

@jmcarp jmcarp force-pushed the jmcarp/conflict branch from b77feb2 to 25bb982 Compare April 2, 2026 03:42
@jmcarp
Copy link
Copy Markdown
Contributor Author

jmcarp commented Apr 2, 2026

This is going to break a whole lot of tests.

Yes, but mostly the kind of test that Claude can fix.

Since we already return ObjectAlreadyExists text perhaps that's a moot point and this change makes sense as-is.

I think that's right. I don't think the choice of the generic 400 over a 409 here was related to obfuscation, because creating a resource would be behind auth, so a malicious user would hit a 401 or 403 before being able to enumerate resources.

This is changeable but it does seem like a breaking API change.

Yes, it's possible that customers are depending on receiving a 400, although I'm not sure how likely that is.

How disruptive would this change be? All things being equal, I think it would be nice to use more specific http status codes, but if it would be annoying to us or users, I'll just close this.

@david-crespo
Copy link
Copy Markdown
Contributor

david-crespo commented Apr 2, 2026

Honestly not sure. I agree 409 is more correct, but the improvement is small enough that it would only have to be a tiny bit inconvenient to not be worth it. There are a couple of spots in the console where we look at the status code, but I think we only rely on it for 404 and 403, not for 400, precisely because the latter is so general that the error code is always more informative.

https://github.com/oxidecomputer/console/blob/8e240f115e03cecc0d0f32e9fc9a73ee739125e3/app/components/ErrorBoundary.tsx?plain=1#L64-L68

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants