You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Sentry KILOCODE-WEB-2828: new error in production #9116
The Google Play RTDN handler fails on the first write of a notification: the event's store account token is bound to the uuid column kilo_pass_store_events.app_account_token, so a non-UUID value aborts the claim insert with SQLSTATE 22P02 before anything else runs. The route answers 500 for that permanent payload error, so Pub/Sub redelivers the same event for days (multi-day bursts in Sentry, backoff-shaped retries in Axiom), and the notification is never recorded as processed, blocking the renewal/cancellation/refund/revocation action it carries. Repository failure-UX guidance asks for a fast, correct failure for work that can never succeed rather than letting the provider retry it; this is the same class of defect the repo has already fixed elsewhere on store notifications (400 for malformed bodies, no throw for non-USD Apple refunds).
Recommended next step: investigate. Confirm the scope and the retention behaviour before choosing the fix surface: establish how many Google Play purchase lineages carry a non-UUID account token and whether the earlier burst's message was dropped (M1, M2), and reconcile with PR ＃7306, which rewrites this exact handler (M3). Then fix in the pinned code path by validating or neutralising the store account token before it is bound to the uuid column and by not answering 500 to a payload that can never succeed (record the event with a validated/null token, or acknowledge and quarantine with an alert), keeping the existing 400/503 handling intact. Deferring would leave an unbounded retry loop on the payment path; no duplicate association is warranted because no other issue or listed work item shares this cause.
Activity
kfab-cloud commentedon Oct 29, 2026
Kfab triage
Provisional classification: suspected bug.
The Google Play RTDN handler fails on the first write of a notification: the event's store account token is bound to the uuid column kilo_pass_store_events.app_account_token, so a non-UUID value aborts the claim insert with SQLSTATE 22P02 before anything else runs. The route answers 500 for that permanent payload error, so Pub/Sub redelivers the same event for days (multi-day bursts in Sentry, backoff-shaped retries in Axiom), and the notification is never recorded as processed, blocking the renewal/cancellation/refund/revocation action it carries. Repository failure-UX guidance asks for a fast, correct failure for work that can never succeed rather than letting the provider retry it; this is the same class of defect the repo has already fixed elsewhere on store notifications (400 for malformed bodies, no throw for non-USD Apple refunds).
Recommended next step: investigate. Confirm the scope and the retention behaviour before choosing the fix surface: establish how many Google Play purchase lineages carry a non-UUID account token and whether the earlier burst's message was dropped (M1, M2), and reconcile with PR ＃7306, which rewrites this exact handler (M3). Then fix in the pinned code path by validating or neutralising the store account token before it is bound to the uuid column and by not answering 500 to a payload that can never succeed (record the event with a validated/null token, or acknowledge and quarantine with an alert), keeping the existing 400/503 handling intact. Deferring would leave an unbounded retry loop on the payment path; no duplicate association is warranted because no other issue or listed work item shares this cause.
Sources:
Triage is complete. This recommendation does not start planning or implementation. Findings and hypotheses are available in the Kfab work item.