Skip to content
Aabha AI Academy

Stage 10 · L39

Give background work its own resources and delivery limits

Optional extension · extended visuals/current Equipment runtime; not original Session 8 implementation

Optional resource implementation checked in isolated PostgreSQL/HTTP fixtures.

Native checkpoint 09

Download starter · Download solution

Use the starter for this stage's focused examples. The cumulative transfer and solution belong at the stage-end capstone. Baseline checks pass; transfer checks initially fail. Downloads contain the matching native starter and solution for this stage.

FastAPI BackgroundTasks schedules in-process work after the response body. It is useful for a small owned demonstration, but it is not a durable queue, broker or delivery guarantee. A process restart can lose work; accepted202 means the request was accepted, not that an external side effect completed.

The demo route receives an equipment ID and schedules read_snapshot. It passes neither the request's session nor an ORM row. The function opens its own SessionLocal, reads the item, constructs a frozen EquipmentSnapshot, closes the session, then captures the plain result. The capture list is an explicit local fixture, not persistent job storage.

The optional independent task adds a priced snapshot. It reads daily_rate as Decimal while the session is owned and returns a frozen PricedEquipmentSnapshot. The test issues actual HTTP with include_rate=true and verifies75.00 after the client/session boundaries close. A decimal string or rounded binary float is not silently substituted for the stored monetary type.

TestClient waits for the ASGI application's background execution before returning in this fixture. A real network client may receive202 before the work finishes. Do not infer production timing or durability from the test client's completion behavior. An exception after response start cannot honestly replace that already sent status.

Work requiring guaranteed execution, retries, idempotency or email publication needs a durable job/outbox design with explicit ownership and recovery. Those facilities are not implemented here. The live article publisher and its schedule are separate systems and are not invoked by this course exercise.

HTTP accepts the local task; Pass equipment ID, not ORM row; Task opens its own Session; Capture frozen priced snapshot; In-process; no durable delivery
HTTP accepts the local task; Pass equipment ID, not ORM row; Task opens its own Session; Capture frozen priced snapshot; In-process; no durable delivery

Follow the running code

Focused lesson example; see the end-of-stage capstone for the cumulative app · stage 09

identifier → fresh owned background session
→ read stored facts → frozen PricedEquipmentSnapshot
→ close session → capture plain Decimal value

202 acceptance ≠ durable execution.

Predict and observe this focused example using the concepts explained above. Its boundary is stated in the focused answer.

Guided lab

  1. Read the explanation and predict the focused example’s outcome.
  2. Implement only the priced background snapshot; reject passing a request session/ORM row. Explain TestClient timing.
  3. Compare the observed outcome with the focused answer and state its boundary.

Expected: The task receives an identifier/capture function, owns its session and builds the frozen Decimal snapshot before closing. The capture remains usable afterward. TestClient waits for in-process task execution; a real network client can receive202 earlier. This is not a queue, outbox or retry/delivery guarantee.

  • In-process work may be lost on restart; accepted202 is not durable execution; passing a request session crosses ownership.

Focused exercise and answer

Complete this focused exercise before reading its answer. The full native transfer is introduced only at the end of the stage.

Your transfer task: Implement only the priced background snapshot; reject passing a request session/ORM row. Explain TestClient timing.

  1. Implement only the priced background snapshot; reject passing a request session/ORM row. Explain TestClient timing.
Inspect the matching answer

This answer addresses the focused exercise above; the cumulative implementation is shown only after the stage prerequisites.

The task receives an identifier/capture function, owns its session and builds the frozen Decimal snapshot before closing. The capture remains usable afterward. TestClient waits for in-process task execution; a real network client can receive202 earlier. This is not a queue, outbox or retry/delivery guarantee.

Check your reasoning

Why pass an ID instead of the ORM row?

Show the explanation

The background task owns a fresh resource scope and returns plain data; it must not depend on a closed request session.

Reading progress

54 lessons remain open to guests. Marking a lesson read records reading only; it does not award assessment credit or a certificate.

Device reading marks require browser storage. Reading is always available.

Sign in or create an account to save separate account progress. Your current page is kept.