dce_002 · Deployment E2E: real GCS 404 — section error must surface
Status: ✓ Passing · Last run: 2026-06-09T06:39:27 · Pipeline: deployment_e2e
· History: 1/1 runs passed (100%)
What was tested
Same flow as dce_001 but the model.pkl is NEVER uploaded. The Python section's _blob.download_to_file(_buf) call raises a real google.api_core.exceptions.NotFound. The production runtime (_execute_one_section in execute_live_refresh.py) must catch this cleanly and surface it as a section error — NOT crash the whole refresh. This is the production-side equivalent of dc_007 (model_missing), but exercising the real exception path instead of a planted RuntimeError.
What we planted in the data
- 500 entities
- Signal strength: 0.50 (sigmoid slope multiplier)
n_new_rows=50
What the system did
- Training rows built: 500
- Features used in model: 3
- Model selected:
DeploymentE2ERunner
What we checked — all assertions passed
| Status | Assertion | Detail |
|---|---|---|
| ✓ | e2e_section_completed_cleanly |
expected section error fired: score_new_rows: The section failed during this refresh. |
How this could have gone wrong
(no assertion descriptions provided)
Why this case matters
When a model artifact disappears (GCS bucket lifecycle, retraining output renamed, IAM revoked), the FE Live tab needs to see a readable error in errors[], not a 500 from the refresh handler. This case proves that path.
Reproducing
# from auto_insight_api/
python -m validation.v2 run dce_002 --pipeline deployment_e2e -v
- Case config:
validation/v2/cases/dce_002_e2e_model_missing.yaml - Data shape:
deployment_e2e_model_missing - Analytics type:
deployment_e2e