Failed jobs sometimes don't list a start or stop time in the "Jobs" list

[brittyazel]

Please confirm the following

• I have checked the current issues for duplicates.
• I understand that Ascender is open source software provided for free and that I might not receive a timely response.

Bug Summary

Starting with the past couple of Ascender releases, sometimes if a job fails it doesn't show as having a start or end time. I don't know exactly the trigger for this condition, but it seems like it might happen if a job is dependent on another job, and the dependency job fails. This means that these failed runs will perpetually be at the top of the list, and their order isn't reflective of any chronology.

It would be great if jobs have a start/stop time listed every single time, regardless of how a job is launched.

Ascender version

25.6.1

Select the relevant components

• UI
• UI (tech preview)
• API
• Docs
• Collection
• CLI
• Other

Installation method

kubernetes

Modifications

no

Ansible version

No response

Operating system

No response

Web browser

No response

Steps to reproduce

Start a job that depends on another job, and have that job fail, and thus fail the dependent job as well.

Expected results

All jobs should have a start and stop time, regardless of if they are successful or not.

Actual results

Sometimes our failed jobs don't have any start/stop time.

Additional information

No response

[quanah]

Reproduced on 25.4.0, and the trigger the report was unsure about is a dependency cascade: a project update
failed, the inventory update depending on it failed, and the jobs depending on that failed — ten rows within
two seconds, every one status: failed with both started and finished NULL. Nothing in the chain ever ran,
so nothing stamped a time.

The cause was UnifiedJob.save() suppressing the timestamp whenever started was NULL, which served
ansible/awx#3988 — a job canceled before it starts, where elapsed time is genuinely meaningless. The
condition was broader than the case it was written for, so a job that failed before starting lost its
timestamp too.

That looks already fixed on main by 7e35de0 (#1020, "Revert parts of 343 as all jobs should have a finished
time"), which stamps every terminal status. The newest release is 25.6.2 from 2026-09-09, which predates it, so
two things would be useful to know:

Which release will carry it? Anyone on 25.6.x or earlier still accumulates these rows.

Will the ordering tolerate the rows that already exist? This is the part a code fix does not reach. Rows
written before the fix keep finished: NULL forever, and since the Jobs list sorts -finished and PostgreSQL
puts NULLs first on a descending sort, those rows stay pinned above every completed job until retention removes
them — 120 days by default. Ordering on COALESCE(finished, canceled_on, modified), or a one-off migration
stamping the existing rows, would fix the symptom for records already in the database.

Worth noting for anyone repairing rows in the meantime: PATCH /api/v2/jobs/<id>/ returns HTTP 405, so it
takes an ORM write from a task pod, and for a job that failed before starting nothing in the record says when —
modified is the only value available.

One consequence beyond the list ordering, in case it argues for the backport: finished__gte, finished__lte
and started__gte cannot match NULL, so these jobs are invisible to every time-bounded query. Failure
reporting under-reports exactly during a cascade, which is when the most jobs fail at once.

Investigated with an LLM (Claude); the cascade, the 405 and the NULL-ordering behavior were each verified by
hand against a running instance.