Single-account escalation
High confidence
Enterprise checkout for STARK-44 is 500ing because the checkout payload has items with missing quantity (None), which trips validate_quantity and bubbles as a server error.
What Nirna found
-
Reporter says multiple STARK-44 users are hitting 500s in enterprise checkout over the past two hours; traceback shows ValueError: invalid quantity None from common/validators.validate_quantity during checkout.source ↗
-
STARK-44 is an active enterprise account.source ↗
-
STARK-44 successfully placed prior orders with explicit item quantities (quantity: 1) last week.source ↗
-
STARK-44 successfully placed prior orders with explicit item quantities (quantity: 1) last week.source ↗
-
STARK-44 successfully placed prior orders with explicit item quantities (quantity: 1) last week.source ↗
-
Reporter notes the issue started around a recent deploy.source ↗
-
validate_quantity raises when quantity is None, enforcing quantity as required.source ↗
What this means
The enterprise checkout path for STARK-44 is sending at least one line item without a quantity field, so item.get("quantity") returns None; validate_quantity rejects it and the exception is currently unhandled, returning a 500. The timing with a recent deploy suggests either a payload shape change on the enterprise form (e.g., using "qty" or omitting the field) or stricter server-side validation started enforcing presence of quantity without defaulting. This looks isolated to STARK-44 given only their account is reported.
Who’s affected
Accounts affected
1
isolated so far
First seen
Jul 28 · 22:47 UTC
Also affects: STARK-44
Recommended fix
Ops change
Apply a per-account request transform for STARK-44 to unblock immediately:
- In Admin > Accounts > STARK-44 > Checkout > Request mappings, add an alias so items[].qty maps to items[].quantity when quantity is missing. JSONPath copy: from $.items[*].qty to $.items[*].quantity (only-if-missing).
- In the same section, set a fallback default for items[].quantity = 1 when neither quantity nor qty is present.
- In Admin > Accounts > STARK-44 > Checkout > Error handling, map ValueError('invalid quantity None') from validators.validate_quantity to a 400 response instead of 500 for checkout_submit so bad requests don’t take down the flow.
- Save and publish the account config, then retry a checkout with STARK-44.
- Monitor error rate for STARK-44 checkout for 30 minutes and remove the fallback once the client payload is corrected.
Suggested replies
Copy-paste ready. Your engineer edits and sends.
Customer reply
We’re seeing your enterprise checkout requests hit our validator with items missing a quantity (coming through as None), which is why you’re getting 500s. We’re putting a server-side mapping in place for STARK-44 to accept qty and to default quantity=1 if it’s missing so your team can complete checkout while we coordinate a client-side fix. Can you confirm if the enterprise checkout form recently changed field names for item quantity (e.g., qty vs quantity)? We’ll update here as soon as the server-side mitigation is live.
Internal note
STARK-44 enterprise checkout 500s due to missing item quantity. Stack shows ValueError: invalid quantity None from validate_quantity during checkout_submit (ticket NRNA-17). Action: in Admin > Accounts > STARK-44 > Checkout > Request mappings, add alias $.items[*].qty -> $.items[*].quantity (only-if-missing) and set default items[*].quantity = 1 when absent. Also map the specific ValueError to HTTP 400 for checkout_submit to stop 500s. Publish config and validate with a POST that omits quantity, expect 400 on bad payloads and 200 on payloads with qty or quantity. Keep the default as a temporary mitigation and coordinate with client to send quantity explicitly.
Why Nirna reached this conclusion
Verdict — Single-account escalation. Only this account is affected; the evidence points to account configuration mismatch and a code change in the failing path.
Confidence — High. Several checks came back strong: account matched from ticket text, recent deploy touched failing path, account configuration mismatch.
Who fixes it — Ops change. Your ops team can fix this without a deploy — the cause is configuration, an entitlement, or a stale cache they already control.
Who’s affected. Only the reporting account is affected in this window.
| Signal | Score |
|---|---|
| Account matched from ticket text | 0.95 |
| Recent deploy touched failing path | 0.72 |
| Account configuration mismatch | 1.00 |
| Code change in the failing path | 1.00 |
| Feature-flag rollout mismatch | 0.00 |
| Patterns matched in your data | 0.90 |
| Similar recent tickets | 1.00 |
| Different accounts affected | 1.00 |
Was this triage right?
Corrections apply the same day. A wrong-account correction with a domain hint updates the routing rules for the next ticket automatically.