[Jobs] Record submitted_at when a job is first queued

[claude]

What

Record a managed job's submitted_at when its task row is first inserted at PENDING (queue-entry time), instead of at the PENDING -> STARTING transition.

Before: submitted_at was written only when a task moved PENDING -> STARTING. Two cases broke as a result:

• No-op jobs (tasks with empty run commands) short-circuit straight to SUCCEEDED without ever passing through STARTING. Their submitted_at stayed NULL, so the "Submitted" column rendered blank in the dashboard and in sky jobs queue.
• Backoff/recovery re-entry: a job that backed off and re-entered STARTING had its submitted_at overwritten with the latest attempt's timestamp, so the displayed submission time drifted forward over time.

After: submitted_at is recorded exactly once, at the moment the job enters the queue, so both no-op jobs and jobs that back off show a stable, correct submission time.

How

• set_pending (sky/jobs/state.py) now writes submitted_at = time.time() when it inserts the task row.
• set_starting_async (sky/jobs/state.py) no longer unconditionally writes submitted_at; it now only backfills it via COALESCE(submitted_at, submit_time), so legacy rows created before this change still get a value while existing values are never clobbered on a (re-)entry into STARTING.
• set_pending_cancelled (sky/jobs/state.py) does not touch submitted_at. A job cancelled while still PENDING keeps the submitted_at recorded at queue-entry — it was still submitted, so this is consistent with jobs that fail before ever starting.

Secondary change

The managed-jobs ORDER BY submitted_at is hardened with NULLS LAST (both the paginated subquery and the final query), so any remaining NULL rows sort deterministically regardless of the DB engine's default NULL ordering, in both ascending and descending order.

Tests

• Code formatting: bash format.sh (yapf + isort clean, pylint 10.00/10 on changed files)
• Added/updated unit tests in tests/unit_tests/test_sky/jobs/test_jobs_state.py:
  • a still-PENDING job has a non-NULL submitted_at
  • a no-op job (PENDING -> RUNNING -> SUCCEEDED, no STARTING) keeps its queue-entry submitted_at
  • the STARTING transition does not clobber an existing submitted_at, but backfills a NULL one
  • a job cancelled while PENDING keeps its queue-entry submitted_at
  • sorting by submitted_at places NULL rows last for both asc and desc (paginated and non-paginated)
• Updated tests/unit_tests/test_sky/skylet/test_managed_jobs_service.py to reflect that a still-PENDING job now reports a non-NULL submitted_at.
• Relevant individual tests: pytest tests/unit_tests/test_sky/jobs/test_jobs_state.py tests/unit_tests/test_sky/skylet/test_managed_jobs_service.py (116 passed)

🤖 Generated with Claude Code

[cg505]

I think we can probably skip this

[claude]

Addressed both review comments:

• Removed the submitted_at NULL-reset in set_pending_cancelled and reverted it to its prior behavior. A job that was queued and then cancelled while still PENDING was still submitted, so it now consistently keeps the submitted_at recorded at queue-entry (set_pending) — matching jobs that fail before starting. Such jobs are now included by the submitted-window filter rather than excluded.
• Added a backcompat-removal TODO on the COALESCE(submitted_at, submit_time) in set_starting_async, marking it for removal ~2 minor versions out, once legacy rows without a submitted_at no longer exist.

Also updated the now-stale window-filter comment to note that the NULL-handling branch only applies to legacy (pre-upgrade) rows, and updated the unit tests to match the new semantics.