Milestone 9 — Control-plane server (API / Redis / S3) ✅
Goal: the pure-CPU control plane — the Boson video API, job status, MP4 upload, render dispatch, and spillover. Code: ~/modal_examples/milestones/m9_control_plane.py.
What was built
A server (stdlib-only, so it runs and self-tests with no external services) implementing:
POST /v1/videos→ createvideo_id, statusqueued, dispatch render async, return immediately.GET /v1/videos/{id}→ status/progress (Redis-like store).GET /v1/videos/{id}/content→ presigned URL when ready; 409 when failed; 202 while processing.- Render dispatch integrates the M8 spillover controller and uploads the MP4 to an S3-like store.
Production mapping: StatusStore → Redis, BlobStore → S3, render_fn → Modal spawn().
How it was validated (python3 m9_control_plane.py)
submit -> video_xxx queued
status -> completed, progress=100
content -> /internal-blob/jobs/video_xxx.mp4 (MP4 bytes verified in store)
back-pressure -> ['queued','queued','failed'] (1 shed at cap)
failed render -> /content 409 (no infinite poll)
VALIDATION PASSED
Code review (separate subagent) — CHANGES NEEDED → fixed
| Finding (severity) | Fix applied |
|---|---|
/content couldn't distinguish failed from in_progress → clients poll forever (HIGH) |
/content now returns 409 + error for failed jobs; added a failed-path test over HTTP |
Shared SpilloverController unlocked → "thread-safe" was false (MED) |
Fixed in M8 (added a lock); verified under the multi-threaded control plane |
| In-memory MP4 hides a streaming/OOM problem (MED) | Documented: prod must stream renderer→S3, not buffer large MP4s in the control plane |
| Queued/worker race | Verified already fixed — POST returns the queued snapshot, not mutable state |
The POST→queued→in_progress→completed→content path and the shed path are both exercised end-to-end over real HTTP.
Status: ✅ validated (API + status + S3 upload + spillover + failed-path).