Repository navigation
fix(api): mark unclaimed_id and block_confirmation responses no-store - #1064
Merged
Merged
Conversation
An edge cache in front of /v1/*/unclaimed_id returned the same id to concurrent callers. Clients that fetch an id per track in parallel (bulk album uploads) then sent two creates with one id, and every create after the first was rejected as a duplicate. The SDK's cache-buster query param has only 1000 values, so it does not prevent this. /block_confirmation is polled until a write's block is indexed; a cached "not yet" delays confirmation past the client's timeout. Both now send Cache-Control: no-store, which edge caches honor when they respect origin headers. Co-Authored-By: Claude Opus 5.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
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.
What
/v1/{users,tracks,playlists,comments,events}/unclaimed_id(and theunclaimed-idaliases) and/block_confirmationnow respond withCache-Control: no-store.Why
An edge cache in front of
/v1/*was storingunclaimed_idresponses keyed on the full URL. Two requests for the same URL within the cache window got the same id, the second as a cacheHIT.noCache=Math.random()*1000) has only 1000 values. In a large album two tracks often end up with the same id. The chain accepts the first create and the indexer rejects the second as "track already exists", so that track is lost while the client still shows it as published. This was observed on mainnet in uploads of 30+ tracks./block_confirmationuntil their block is indexed. A cached "not yet" can push confirmation past the client's timeout, which triggers retries.Edge caches that respect origin headers will no longer store these responses, whatever cache rules exist in front of the API. This complements disabling the cache rule; it doesn't replace fixing the SDK's cache-buster or confirming that the entity exists after a write.
Tests
TestUnclaimedIdAndBlockConfirmationAreNotCacheablechecks all ten routes. It fails on main for every route and passes with this change.TestBlockConfirmationand the eventsunclaimed_idtests still pass.🤖 Generated with Claude Code