Creating a job with both cron_expr and run_at returns a 500 instead of a 400

API consumers depend on clean 4xx errors to build correct client-side validation and debug their own integration quickly. When a client mistake (setting both scheduling fields) surfaces as an opaque 500 instead of a clear "these two fields are mutually exclusive" 400, the client's developer wastes time assuming it's a chronos outage or a database problem, files a support ticket, and on-call has to dig through logs to find a Postgres constraint violation a one-line validation check would have caught at the door. It also pollutes error-rate dashboards and alerting with 500s that aren't actually server failures.

internal/api/jobs_handler.go's createJob validates that at least one of cron_expr/run_at is set, but no longer validates that they aren't both set. A request with both fields reaches s.jobs.Create, which reaches Postgres, which rejects the insert because of the jobs_schedule_check CHECK constraint. createJob's generic error handling for s.jobs.Create failures reports any error as a bare HTTP 500.

curl -i -X POST localhost:8080/v1/jobs
-H 'Content-Type: application/json'
-d '{"name":"x","cron_expr":"* * * * *","run_at":"2030-01-01T00:00:00Z","target_url":"http://example.com"}'

Observe: HTTP/1.1 500 Internal Server Error

This is exactly the kind of validation that belongs at the API boundary, not the database: the constraint already exists at the DB layer as a correctness backstop, but relying on it alone means every violation surfaces as an undifferentiated 500 with no actionable message, at the cost of a round-trip to Postgres just to find out the request was malformed.

createJob already has a check just above this one (req.CronExpr == nil && req.RunAt == nil, "exactly one ... is required"). Look for its sibling check on the opposite condition.