dch_001 · Deployment Handler: real handle_render_live → Firestore round-trip
Status: ✓ Passing · Last run: 2026-06-09T06:54:04 · Pipeline: deployment_handler
· History: 1/4 runs passed (25%)
What was tested
Drives deployment_composer_api.handle_render_live against a real Firestore project document. Setup: 1. Train a sklearn model, joblib.dump to GCS. 2. Upload source data to BigQuery. 3. Write a real DeploymentSpec to projects/validation_dch_<uid> in Firestore — with sections_for_live, style_reference_html, trigger, input, model_uri, etc.
Then call handle_render_live(project_id, user_id, db, bq_client) exactly the way the Cloud Scheduler does at /projects/<id>/deployment/render. Assertions cover the FULL handler contract: - HTTP status 200, response body has html, generated_at, errors, n_sections. - html is non-empty (re_render_html actually produced HTML — catches LLM API key, prompt, or model-id breakage). - errors is empty. - projects/<id>.deployment_spec.live_artifact was written back with the same html + a generated_at timestamp — catches "handler returns ok but never persists, leaving the FE Live tab permanently stale."
What we planted in the data
- 300 entities
- Signal strength: 0.50 (sigmoid slope multiplier)
n_new_rows=30
What the system did
- Model selected:
DeploymentHandlerRunner
What we checked — all assertions passed
| Status | Assertion | Detail |
|---|---|---|
| ✓ | handler_returns_200 |
handler returned 200 with body keys: errors, generated_at, html, n_sections |
| ✓ | handler_html_non_empty |
handler returned 8625 chars of html |
| ✓ | handler_errors_empty |
handler returned no errors |
| ✓ | live_artifact_persisted |
live_artifact written: 8625 chars html, generated_at=2026-06-09T06:54:03, errors=[] |
How this could have gone wrong
(no assertion descriptions provided)
Why this case matters
This is the function the Cloud Scheduler hits by HTTP every cron tick. If Firestore serialization drifts, or the LLM prompt for re_render_html stops eliciting HTML, or the live_artifact write-back silently fails — Yifan's deployment looks broken on the Live tab even though the model and BQ are fine. This case catches all three at the same layer they happen in production. Cost: invokes Claude Sonnet via re_render_html (~$0.01) AND uses real Firestore + GCS + BQ. Slower than the dce_* suite (~30s) but this is the only test that exercises the full HTTP handler.
Reproducing
# from auto_insight_api/
python -m validation.v2 run dch_001 --pipeline deployment_handler -v
- Case config:
validation/v2/cases/dch_001_handler_happy.yaml - Data shape:
deployment_handler_happy - Analytics type:
deployment_handler