Bug Triage Report

1. Triage

Severity P0 (Blocker). Every user is blocked at login: the system is effectively down for the whole product. No workaround exists. This is the definition of a blocker.

Business impact. Total outage of all authenticated flows. Every minute is lost sessions and revenue. Page the on-call now.

2. Root cause

Likely cause. The 2am deploy shipped a config or env change; the auth service cannot reach its token signing key or the session store, so every login 500s.

Related components. auth service, secret/config store, session store

Investigate.

1. Diff the 2am deploy against the last known good.
2. Check auth service startup logs for a missing env var or unreachable dependency.
3. Confirm the signing key / session store is reachable from the new pods.

Check first: auth service error logs, deploy pipeline diff, infra alerts dashboard

3. Test strategy

Verification. A standard user logs in successfully and reaches the dashboard after the rollback or fix.

Regression.

• Login with valid credentials.
• Login with invalid credentials returns a clean 401, not a 500.
• Session persists across a page refresh.

Edge cases.

• Login immediately after a deploy (smoke gate in the pipeline).

Automation. Add a post-deploy Playwright smoke that logs in and fails the deploy if login is not 200.

1. Triage

Severity P1 (Critical). Revenue path is affected: the discount a customer was promised disappears without warning and the total resets to full price. There is a workaround (do not double-click) but it is invisible to the user, so real orders are placed at the wrong price. Not P0 because the site stays up and no data is lost.

Business impact. Customers charged more than the shown discounted price. Direct trust and refund cost, and a likely spike in support tickets during any promo.

2. Root cause

Likely cause. The second Apply dispatches the coupon action again; the reducer recomputes the cart total from a state where the discount object is already consumed, so `discount` is undefined and the total falls back to the list price.

Related components. cart total recompute, coupon reducer, checkout summary component

Investigate.

1. Reproduce with the network tab open: confirm a second /apply-coupon call fires on the second click.
2. Log the reducer state before and after the second dispatch; check whether `discount` is null.
3. Check whether Apply is debounced or disabled after the first success.

Check first: checkout service logs, front-end error tracker (coupon reducer TypeError)

3. Test strategy

Verification. Apply SAVE10 twice in a row; total stays discounted and a 'coupon already applied' message shows instead of resetting.

Regression.

• Apply then remove then re-apply a coupon; total is correct at each step.
• Apply an invalid coupon after a valid one; the valid discount is not lost.
• Refresh the page after applying; discount persists.
• Apply a coupon, change cart quantity; discount recalculates correctly.

Edge cases.

• Rapid triple-click on Apply.
• Two tabs applying different coupons on the same cart.

Automation. Playwright TS: assert on the total locator after a double click, and intercept /apply-coupon to assert it is called at most once.

1. Triage

Severity P4 (Trivial). Cosmetic text in the footer. No functional impact, no user is blocked. This is a trivial fix, and inflating it would crowd out real work.

Business impact. Minor polish. Slightly dated look. Safe to batch with the next UI cleanup.

2. Root cause

Likely cause. The year is hard-coded in the footer template instead of derived from the current date.

Related components. footer component

Investigate.

1. Grep the footer template for the literal 2025.

Check first: footer component source

3. Test strategy

Verification. Footer shows the current year.

Regression.

• Year renders correctly on 1 Jan (boundary).

Edge cases.

• Timezone near midnight on New Year.

Automation. Trivial unit assertion on the rendered year; not worth an e2e.