Single-account escalation
High confidence
STARK-44 enterprise checkout is 500ing because calculate_total calls validate_quantity on an item with quantity=None, which raises ValueError and bubbles up as a 500 right after the recent deploy window.
What Nirna found
-
Jira ticket shows checkout 500s for STARK-44 with traceback ending in ValueError: invalid quantity None, reported over the past two hours and noted as starting around a recent deploy.source ↗
-
A prior ticket for the same issue includes the same traceback and timeline for STARK-44.source ↗
-
STARK-44 is an active enterprise account.source ↗
-
validate_quantity raises on None and enforces bounds; this is the failure site.source ↗
What this means
An item in the cart lacks a quantity, so item.get("quantity") returns None in calculate_total; validate_quantity raises on None and the ValueError is not handled at the route layer, returning a 500 instead of rejecting the request or defaulting the quantity. This surfaced right after a deploy window, suggesting a new code path or payload shape made it easier to submit items without quantity.
Who’s affected
Accounts affected
2
steady
First seen
Jul 28 · 22:47 UTC
Also affects: STARK-44
Recommended fix
Code change
Change validators to treat a missing quantity as a safe default (1) instead of raising, so checkout cannot 500 on None. File: nirna/demo/codebase/src/bindu_bazaar/common/validators.py, lines 60-67 (sha 8b3688e3). Replace the None branch with a coercion:
- if value is None: return 1
- Keep existing bounds checks for <1 and >999.
Also add a unit test for validate_quantity(None) => 1 to close the current test coverage gap.
- nirna/demo/codebase/src/bindu_bazaar/common/validators.py:60–67 @ 8b3688e
Suggested replies
Copy-paste ready. Your engineer edits and sends.
Customer reply
We’re seeing checkout fail with a 500 because one of the line items has no quantity; the backend rejects quantity=None and throws, which returns a 500. We’re landing a hotfix to safely accept missing quantity by defaulting it to 1 so this can’t 500. Once deployed we’ll confirm on our side; you can retry the checkout and it should go through.
Internal note
STARK-44 checkouts are 500ing due to ValueError from validate_quantity on quantity=None (see traceback). Failure site: nirna/demo/codebase/src/bindu_bazaar/common/validators.py L60-67 (sha 8b3688e3). Proposed patch: coerce None -> 1, retain bounds checks. This avoids unhandled ValueError in the route. Follow-up: add unit test coverage (currently none for validate_quantity per e24).
Engineering handoff
Bug: Checkout 500 on cart items with missing quantity. Traceback ends in validate_quantity raising on None.
Change:
- File: nirna/demo/codebase/src/bindu_bazaar/common/validators.py (sha 8b3688e3)
- Lines 60-67
- Edit:
def validate_quantity(value: int | None) -> int:
- if value is None:
- raise ValueError("quantity is required")
+ if value is None:
+ return 1
if value < 1:
raise ValueError(f"quantity must be at least 1: {value}")
if value > 999:
raise ValueError(f"quantity exceeds maximum 999: {value}")
return value
Rationale: Prevents ValueError bubbling to a 500 when clients omit quantity; keeps existing bounds. Add unit test: validate_quantity(None) == 1. After merge, deploy and verify STARK-44 checkout path with an item missing quantity no longer 500s.
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 — Code change. This needs engineering: a recent deploy touched the code path that failed and the failing path changed in that deploy. The account's state also looks wrong, but the code evidence is the part anyone can act on — start there.
Who’s affected. Cross-account log check found the same error in 1 other accounts within the window: STARK-44.
| Signal | Score |
|---|---|
| Account matched from ticket text | 0.95 |
| Recent deploy touched failing path | 0.95 |
| 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 | 2.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.