# QA test cases — job execution on the new dashboard

Derived from QA feedback (2026-07-29) on the new dashboard. Cross-references:
`docs/job-lifecycle-qa.md` (state machine), `docs/feature-list.md` (items 11-16).

## Pull image jobs

| # | Case | Steps | Expected | Notes |
|---|------|-------|----------|-------|
| P1 | Pull job survives a busy MLC | Start a pull job; put the MLC under load (or run 2+ jobs); watch the job for 5+ minutes | Job stays RUNNING on the dashboard as long as the MLC is actually processing | Currently FAILS ~2 min in: the 60s health sweep with its 2s probe timeout marks the MLC NOT ACTIVE and flips the job INCOMPLETE (feature 12a) |
| P2 | Dashboard-vs-MLC consistency after auto-stop | After a job is auto-marked INCOMPLETE, check MLC logs | MLC must NOT still be running the job — a stop should have been dispatched | Currently FAILS: no stop is sent on reconcile; MLC keeps pulling (feature 12b) |
| P3 | MLC-driven status updates during pull | Run a pull job; watch `job.status` and `api_callback_count` | MLC posts status callbacks (`/add_benchmark_result` alias) and the row reflects them | QA confirmed callbacks arrive during image pull — the "image jobs have no async callback" design assumption only holds for THIS status flow, not universally; verify a late callback never resurrects a terminal row |
| P4 | Pull job stop | Stop a running pull job from the dashboard | Row → STOPPED immediately (sync stop); MLC log shows the `init: stop` push | |

## Push image jobs (Type 1 / Type 2) — NOT YET TESTED by QA

| # | Case | Steps | Expected |
|---|------|-------|----------|
| U1 | Type1 push start/stop | Configure an image camera with Type1 Push; start, verify RUNNING, stop | Same lifecycle as pull (sync accept → RUNNING; stop → STOPPED) |
| U2 | Type2 push start/stop | Same with Type2 Push | Same |
| U3 | Camera-config validation | The camera-configuration errors that blocked QA's pull setup: reproduce and document the exact failing config | Clear 4xx with an actionable message, not a silent MLC failure |

## Video (live) jobs

| # | Case | Steps | Expected | Notes |
|---|------|-------|----------|-------|
| V1 | Start reaches RUNNING | Start a live job on a real MLC; confirm inference in MLC logs; watch `job.status` AND the dashboard | Backend flips START_PENDING → RUNNING when the MLC's start callback lands (~18s observed on prod — this WORKS, verify as regression). The DASHBOARD must show the flip without a manual page reload | UI currently FAILS to refresh (feature 14); backend passes — check `job.job_start` is set |
| V2 | Stop reaches STOPPED without abort | Stop a RUNNING live job | STOP_PENDING → STOPPED without operator abort, via the stop-confirmation timeout (≥ 1 hour — a legitimate confirmation can take a long time; never terminalize earlier). A callback arriving inside the window must win and flip the row immediately | Currently FAILS — VIDEO ONLY: the MLC never sends a stop confirmation for live streams (`api_callback_count` stays at 1), so the row waits forever (feature 13). Verify in MLC logs the stream did stop when dispatch succeeded |
| V3 | Abort escape hatch | Abort a START_PENDING/STOP_PENDING job | Row → STOPPED immediately; MLC capacity slot released | Passing today |

## Configuration / UI

| # | Case | Steps | Expected | Notes |
|---|------|-------|----------|-------|
| C1 | Bundle picker scoping | Open device add/edit as a tenant admin; open the Service Bundle dropdown | Only bundles associated with the device's company (junction rows) are listed | Currently FAILS: all bundles shown (feature 15) |
| C2 | Job types match media type | Device with Source Media Type=Video → only live job controls; Image → only Pull/Type1/Type2 | No invalid job type offered (feature 16) | |
| C3 | Camera card state after start | Start a job; check the ACTIVE/INACTIVE chip on the COD camera card | Chip goes ACTIVE (green) while the job runs | Currently FAILS: stays INACTIVE — `streamStatus` is a dead column (feature 11) |
| C4 | mlc_config company filter | `GET /config/infra/mlc_config` as/for a specific company | Only that company's configs returned | Feature-list items 1-2 |
| C5 | Service bundle sources | Create bundles with a `file://` URL and an S3 `https://` URL; run a job with each | Both init the MLC successfully | QA confirmed PASSING — keep as regression case |

## Confirmed-working (regression guard)

- Image pull status is updated automatically by the MLC (P3).
- Service bundles work from both local files and AWS downloads (C5).
- All configuration features needed to start image and video jobs exist on the
  new dashboard (parity with the old application).