POST /jobs' duration cap validates the wrong request field

Settings.job_max_duration_seconds exists so an operator can cap how long a single simulated job is allowed to run, independent of the schema's own hard 600-second ceiling -- e.g. lowering it during a capacity-constrained window, or because a real transcoder backing this API in production has its own SLA-driven duration limit. Right now that setting does nothing useful: the check compares the wrong field, so any operator who lowers it for capacity reasons and trusts it to actually protect their instance is unprotected -- clients can still submit jobs right up to the schema's 600-second hard ceiling regardless of what this setting says.

The check compares req.steps (an integer, hard-capped at 50 by the schema) against settings.job_max_duration_seconds (a duration, typically in the hundreds). The error message still correctly says duration_seconds -- it's the check itself that's wrong, not the message.

1. pytest practice_tickets/tests/test_ticket_04_duration_cap_checks_wrong_field.py -v
2. Or manually: configure Settings(job_max_duration_seconds=30.0), then with .

This reads like a copy-paste/refactor slip -- two request fields (duration_seconds, steps) and two settings fields (job_max_duration_seconds, job_max_steps) exist side by side, and the wrong pairing got wired up. Nothing type-checks this: both sides of the comparison are numeric, so it's perfectly valid Python that just compares two unrelated quantities. The error message string (still correctly naming duration_seconds) is actually a useful clue -- it tells you what the check was supposed to compare.

Look at the four related names involved: req.duration_seconds, req.steps, settings.job_max_duration_seconds, settings.job_max_steps. The check currently pairs one request field with the other field's cap.