Delete the test snapshot in teardown so failures do not orphan it

[kaidaguerre]

The snapshot acceptance tests upload a snapshot to turbot-ops/clitesting and then delete it — the existing comment says why: "to avoid exceeding quota".

But the DELETE was the last statement of each test body, so it only ran when every assertion passed. Any failure after the upload left the snapshot in the workspace permanently, and these tests upload on every CI run.

Change

Capture the delete URL immediately after the upload, and move the DELETE into a bats teardown(), which runs whether the test passes or fails. req_url is reset in setup() and the DELETE is guarded on it being non-empty, so a skipped test or an upload that never produced a URL is a no-op.

No assertion or expected-output file is touched.

Verification

bats test_files/snapshot.bats with no SPIPETOOLS_TOKEN — parses and skips all three cleanly, teardown no-ops on the empty URL.

The teardown behaviour itself was proven with an equivalent throwaway bats file, since the real one needs a token:

@test "upload succeeds then assertion fails" { req_url="https://pipes/api/v0/snapshot/abc"; [ "1" = "2" ]; }
@test "upload itself fails before url captured"  { false; req_url="never-set"; }

teardown log:

DELETED:https://pipes/api/v0/snapshot/abc
NO_URL

So a post-upload failure still deletes, and a pre-URL failure skips cleanly.

What this does not fix

The current CI failures are 504 Gateway Timeout from the snapshot publish endpoint:

# Error: failed to publish snapshot to turbot-ops/clitesting: 504 Gateway Timeout

A timed-out publish never returns a URL, so there is nothing for teardown to delete — and a 504 is a gateway timeout rather than a rejection, so the backend insert may still have completed. Any snapshots already orphaned in turbot-ops/clitesting need purging in Pipes directly; this PR only stops the pile growing from ordinary test failures.

Worth noting the write path is the only thing affected — database_precedence.bats queries the same workspace with the same token and passes in under a minute, so the workspace and credentials are fine.

Separately, newPipesClient in pipe-fittings builds its HTTP client from pipes.NewConfiguration() with no timeout and no retry, so any slow Pipes call becomes a hard CI failure across steampipe, powerpipe and flowpipe. Adding a timeout plus one retry on 5xx there would make all three resilient, but that affects every consumer so it is left as its own decision.

🤖 Generated with Claude Code