2 min lesson
Task 3 - dedup retries into logical attempts before a failure rate
Take "Task 3 - dedup retries into logical attempts before a failure rate" step by step, then finish with the result that proves it worked.
Step 1 of 2
Task 3 - dedup retries into logical attempts before a failure rate
A flaky network produces three rows for one user intent: two timeouts then an ok. Counting raw rows reports a 67% failure rate for something the user experienced as a success. Roll up to the logical attempt first.
- 1Define the logical attempt. Group retries under one key -
request_idor a window ofuser_id+ same prompt within N seconds if no request_id exists. - 2Collapse status with a precedence rule. A logical attempt succeeds if any of its tries succeeded; it fails only if every try failed. Decide and state the rule.
- 3Compute the rate on attempts, not rows. Failure rate = failed logical attempts / total logical attempts.
- 4Sanity-check the denominator. Confirm attempt count is below row count by roughly your retry rate; if they're equal, your dedup didn't fire.
WITH attempt AS (
SELECT
request_id,
BOOL_OR(status = 'ok') AS any_ok,
COUNT(*) AS tries
FROM interaction_events
WHERE event_type IN ('success', 'error', 'timeout')
GROUP BY request_id
)
SELECT
COUNT(*) AS logical_attempts,
COUNT(*) FILTER (WHERE NOT any_ok) AS failed_attempts,
ROUND(100.0 * COUNT(*) FILTER (WHERE NOT any_ok)
/ COUNT(*), 2) AS failure_rate_pct,
ROUND(AVG(tries), 2) AS avg_tries
FROM attempt;Narrate two sanity checks per query without being asked: one on the denominator (does N look right for the window) and one on a known-good slice (does the newest client_version show fewer timeouts than last month). The screener is grading whether you trust-but-verify your own numbers. Silent correctness reads as luck; narrated correctness reads as rigor.
Learn more
Full explanation
Self-score the run
Self-score the run
- Axis
- Correctness
- Weak (1-2)
- Averaged latency; counted raw rows as failures.
- Strong (4-5)
- Percentiles, attempt-level dedup, correct denominators.
- Axis
- Rigor
- Weak (1-2)
- Returned a number with no checks.
- Strong (4-5)
- Stated assumptions; ran a denominator and a known-slice check.
- Axis
- Communication
- Weak (1-2)
- Typed in silence.
- Strong (4-5)
- Narrated each metric definition and why before running it.
- Axis
- Speed
- Weak (1-2)
- Stuck on syntax; ran out of clock.
- Strong (4-5)
- Reached three working answers inside the hour with time to sanity-check.
| Axis | Weak (1-2) | Strong (4-5) |
|---|---|---|
| Correctness | Averaged latency; counted raw rows as failures. | Percentiles, attempt-level dedup, correct denominators. |
| Rigor | Returned a number with no checks. | Stated assumptions; ran a denominator and a known-slice check. |
| Communication | Typed in silence. | Narrated each metric definition and why before running it. |
| Speed | Stuck on syntax; ran out of clock. | Reached three working answers inside the hour with time to sanity-check. |
Anything you score 3 or below is a rep to repeat before the real screen.
QYour raw events table shows a 9% timeout rate. After grouping by request_id and treating an attempt as successful if any try succeeded, it drops to 3%. Which number do you report as the reliability metric and why?