Split the delete of a processing result and its trace - #48
Merged
Merged
Conversation
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
force-pushed
the
raf/split-trace-delete
branch
from
August 30, 2026 14:03
85235e1 to
5becb4b
Compare
rferreira
marked this pull request as draft
August 30, 2026 14:11
rferreira
marked this pull request as ready for review
August 30, 2026 14:12
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.
The processing result and its processing trace are separate resources — separate readers, each with its own 404 — and the delete now treats them that way. Generated from the API's own OpenAPI output and reindented to this file's sequence style; the transform was verified by checking it reproduces the existing, unchanged trace
get:block byte for byte.This supersedes #47 and includes everything that was in it. #47 documented
DELETE /v2.2/files/{id}as removing the result and its trace; that cascade is gone, so merging it would publish a contract that is about to stop being true, then amend it days later. One change, one publish. Close #47 when this lands.What changed
DELETE /v2.2/files/{id}/trace— new. Removes the trace alone, leaving the result readable.DELETE /v2.2/files/{id}— removes the result alone. The description says so outright, and points at where the trace lives: a customer deleting a result should not have to discover by accident that the findings are still readable at the trace endpoint. Erasing a scan entirely is two calls.Both carry the 403 (an API key is required — a temporary auth token authenticates as the key that minted it and is refused) and the 404 (there was nothing to delete, which is also what a repeated delete returns) that #47 introduced, plus the
ErrorResponsebody on the 401 that the authentication entry point has always returned regardless of method.Checks
vacuum lint -d --no-styleandopenapi-generator-cli validate --recommendboth exit 0. The new operation adds 3oas3-missing-examplewarnings and 4description-duplicationinforms — the same classes every other response block in the file already produces.Merge order
The API change ships first; this documents behaviour that goes with it, and merging here publishes to the docs site on push to
main.