Conversation
Taken from the springdoc output of jackfruit#1560, which changes the endpoint the spec was written against: * 403 - the delete now requires an api key. A temporary auth token carries ROLE_USER and authenticates as the key that minted it, so it was able to erase every result filed under that key * 404 - the delete reports whether anything was there. S3 answers the delete of a missing key as a success, so the old blanket 204 could not tell a caller that it had erased nothing. A repeated delete of the same id returns 404 too * 401 - carries an ErrorResponse body, which it always did: the entry point writes one regardless of method Also drops "hard" from the summary, which described the implementation rather than the contract. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Author
rferreira
added a commit
that referenced
this pull request
Aug 30, 2026
The result and its trace are separate resources - separate readers, each with its own 404 - so deleting one no longer removes the other, and supersedes #47, whose wording describes a cascade that is no longer how the API behaves. * adds DELETE /v2.2/files/{id}/trace, which removes the trace alone * DELETE /v2.2/files/{id} removes the result alone, and its description says so outright - a customer deleting a result must not assume the findings went with it, since they stay readable at the trace endpoint until deleted there * both carry the 403 and 404 that #47 introduced, and the ErrorResponse body on the 401 that was always being returned Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
rferreira
added a commit
that referenced
this pull request
Aug 30, 2026
The result and its trace are separate resources - separate readers, each with its own 404 - so deleting one no longer removes the other, and supersedes #47, whose wording describes a cascade that is no longer how the API behaves. * adds DELETE /v2.2/files/{id}/trace, which removes the trace alone * DELETE /v2.2/files/{id} removes the result alone, and its description says so outright - a customer deleting a result must not assume the findings went with it, since they stay readable at the trace endpoint until deleted there * both carry the 403 and 404 that #47 introduced, and the ErrorResponse body on the 401 that was always being returned Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Superseded by #48 — see that PR for the full contract.
Corrected the
DELETE /v2.2/files/{id}documentation: the 401 carries anErrorResponsebody (the authentication entry point returns one regardless of method), and the operation answers 403 when the credentials are not privileged enough to delete, and 404 when there was nothing to delete.