Repository navigation
feat(play): carry Google's structured error identifiers into failure receipts - #836
Merged
stamp-build[bot] merged 1 commit intoOct 29, 2026
Conversation
…receipts A failed mapping upload on 2026-10-29 (receipt 2d5a7891) reported only provider_cause VERSION_CODE_CONFLICT: the classifier matches any message that mentions a version code, and Google's own identifiers were dropped, so the real reason could not be read without log access (which nobody has). The adapter now attaches provider_identifiers (error.status, error.code, errors[].reason, details[].@type/reason/domain), each shape-checked as an identifier (camelCase or UPPER_SNAKE; googleapis domain; google.rpc @type); Google's prose is still only sha256 + length. The worker re-validates them in receiptCause before persisting. 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.
Why
The resumable retry of the 1.17.0 mapping backfill failed (receipt
2d5a7891,play_upload_interrupted, http 400). The receipt only saysprovider_cause: VERSION_CODE_CONFLICT. That category matches any Google message that mentions a version code (provider_errors.ts,/version ?code/i), and Google's own identifiers were dropped. Nobody has adapter log access, so the real reason cannot be read. Volta chose option 2 in #joint-hands: carry Google's structured identifiers, keep prose out.What
Adapter:
playRejectionattachescause_detail.provider_identifiers, keeping the source field so a reader can see where Google named the condition:status(error.status);http_code(error.code, integer);errors_reasons(errors[].reason);details[](@type/reason/domain).Every value is shape-checked: reasons/status must be camelCase or UPPER_SNAKE (no dots, hyphens or slashes, so token-shaped values such as
ya29.…,1//…orhidden-secretcan never pass),domainmust be*.googleapis.com, and@typemust betype.googleapis.com/…. Lists are capped at 8. Google's prose is still onlymessage_sha256+message_length.Worker:
receiptCausere-validatesprovider_identifierswith the same rules before persisting; unknown keys are dropped. Upload-protocol failures (play_upload_*) carry it too, since they reuseplayRejection's cause.Contract change, deliberate:
provider_errors.test.tsused to assert that the caller result does not contain validation reasons. It now asserts that identifiers are present and prose is not. The comment explains why.Tests
@typeand metadata are all dropped. There is also a case for a body without identifiers.google_play_distribution.test.ts: 119/119. A new case checks the receipt persists the identifiers and drops off-shape values and unknown keys.tsc --noEmitis clean for adapter and worker.After merge
Deploy adapter → worker. Then rerun the 11700009
upload-symbolscommit once, for the sole purpose of reading the identifiers.🤖 Generated with Claude Code