Page 1 of 8~112 min topic

Webhook lab

Define the service boundary and ship target

Ship a falsifiable slice of **FastAPI receiver for batch-index completion events → durable queue** — success is valid event → 202 + one queue message; replay same event_id → 202 no duplicate work, not a polished screenshot.

~14 min this pageOutcome contract

1Try it yourself

Decision drill

Webhook lab

Webhooks push events — polling pulls. Verify signatures before acting.

Integration safety70%

1/3Nightly index job finished.

2Learn the idea

Read

Name the operable slice

This lab builds FastAPI receiver for batch-index completion events → durable queue. The human in the loop is indexer worker waiting on provider batch.completed callbacks. Scope is intentionally narrower than “make AI reliable”: you will prove one oracle — valid event → 202 + one queue message; replay same event_id → 202 no duplicate work — and one invariant — verify HMAC signature + timestamp skew ≤ 5m; enqueue idempotent by event_id. Record non-goals in your notes so a later change cannot silently expand authority. The incident mnemonic for the chapter is HOOK-SIG-OFF-16; design as if that ticket is already written and you are filling evidence.

Read

Write the acceptance contract

Turn the oracle into a table: input fixture, expected observable, prohibited side effect, owner, latency/cost ceiling. Separate model taste from software correctness — transport, auth, parsing, and termination must be deterministic even when generated text varies. Primary metric family: webhook_accept_total and duplicate_suppressed_total. Averages without a denominator or revision label do not gate release. Fake external dependencies in unit tests; live calls wait until fakes pass.

Read

Implementation artifact

MAX_SKEW_S = 300
HEADER_SIG = "X-Signature-256"

Read

Freeze the first red test

Before implementation, encode a failing check that would have caught signature optional in staging config accidentally shipped to prod. That failure is the pedagogical north star for later pages: contracts reject it, happy path never performs it, validation asserts it, failure-handling contains it, observability detects it, security-ops prevents privilege tricks around it, and mastery replays it in a drill. Endpoint under study: POST /webhooks/batch-index.

Read

Stage depth

Capacity note for planners: estimate peak demand on POST /webhooks/batch-index and the cost ceiling for a failed retry storm. Write the abort conditions — unbounded spend, cross-tenant leakage, or inability to roll back — before you enjoy the first green test. Prefer synthetic fixtures shaped like production over anonymized production dumps you cannot share in class. When you are tempted to widen scope, re-read the oracle (valid event → 202 + one queue message; replay same event_id → 202 no duplicate work) and cut features that do not serve it. The teaching outcome is judgment under constraints: indexer worker waiting on provider batch.completed callbacks gets a trustworthy control, not a kitchen-sink framework. Keep the language of release decisions: promote, hold, or roll back — never “see if it gets better.”

Read

Field notes for `webhook-lab` / `lab-goal`

Decide what will live in version control on day one: fixtures, contract markdown, and a failing test name. Write the cost ceiling as a hard number with currency and period. If the lab involves clusters, name the non-prod context you will use and forbid prod kubecontexts in scripts. Capture the baseline metric once before changing code so later gains are comparative. Refuse tools that hide the request path behind magic macros until the oracle is green on fakes. Your README section for this page should be five lines or fewer and still falsifiable. In this chapter the product is FastAPI receiver for batch-index completion events → durable queue, the human stakeholder is indexer worker waiting on provider batch.completed callbacks, and the incident id you design against is HOOK-SIG-OFF-16. Re-state the oracle in your notes — valid event → 202 + one queue message; replay same event_id → 202 no duplicate work — and keep the invariant visible: verify HMAC signature + timestamp skew ≤ 5m; enqueue idempotent by event_id. Track webhook_accept_total and duplicate_suppressed_total as the scoreboard. Surface under change control: POST /webhooks/batch-index. If you only have forty minutes, finish the fixture for signature optional in staging config accidentally shipped to prod before polishing UI. Promotion language stays ternary: promote, hold, or roll back based on evidence, not hope.

Go deeper

Before you start

Why this matters

Write the single done-definition a reviewer would accept for Webhook lab (HOOK-SIG-OFF-16). Include the numeric gate hidden in this oracle: valid event → 202 + one queue message; replay same event_id → 202 no duplicate work. Then name the fake success you refuse: a demo that ignores signature optional in staging config accidentally shipped to prod. Keep the sentence beside your editor; every later page should make this sentence easier to prove.

Check your understanding

Page assessment

Answer from memory. Completion is saved from this evidence, not from opening the next page.

1. Is the oracle (valid event → 202 + one queue message; replay same event_id → 202 no duplicate work) falsifiable from a fixture?
2. Is the invariant (verify HMAC signature + timestamp skew ≤ 5m; enqueue idempotent by event_id) stated without hand-waving?
3. Does the contract name HOOK-SIG-OFF-16 as a risk you design against?

All responses are required.