clarify the link between dismissed operations and job gone http errors

[fmigneault]

As it was reported during the SWG meeting on 2026-06-22, the dismissed operation manages both "removing the job" and "removing its artifacts" (and potentially more...). While the standard remains open to "how" to perform their "removal" to allow implementation flexibility (e.g.: actual delete, "hide / soft-delete" them, or a mixture of data management strategies), it was not really clear how "HTTP 410 Gone" status could be used to reflect the dismissed status of the job. Notably, the permissions are defined under the "Core" (section 7) which made them hard to identify in the context of "Dismissed" (section 14).

This makes the intention clearer with explicit links and a small introduction of what the operation is for.

[aurore7]

One of our developers would needs that distinction to filter by status when retrieving a list of jobs and to know when the job was dismissed on purpose not just expired. Maybe add something like a data-dismissed and job-dismissed status ?

[fmigneault]

@aurore7
The intended strategy is a follows:

1. If the job is dismissed on purpose (DELETE /jobs/{jobId}), then status: dismissed is set.
   At that point, there are 2 possibilities:

   1. Requesting GET /jobs/{jobId} still returns HTTP 200 OK with status: dismissed, which acknowledge the status, but data cleanup might still be pending.
   2. Requesting GET /jobs/{jobId} returns HTTP 410 Gone, indicating that it did exist (since not 404) and the artifacts are actually cleaned up.
   3. After the 410 Gone is ackknowledged by some entity, servers are free to choose if "final removal" of the job is performed or not (hence following requests will do 404).

2. If the job expired, it either:

   1. remained in status: accepted for too long (internal server / implementation-specific logic)
   2. did not complete successfully (status: failed)

   In each case, some DELETE /jobs/{jobId} must b eexplicitly sent to cancel it (goes to 1i above)

Therefore, the job listing depends entirely on how you manage 1iii.
Once a job has been dismissed, you may consider it not yet cleaned up, while omitting it from the list could mean it was cleared properly. Inversely, you might want to retain that job trace even after cleanup.

Another option could also be to consider "expired" as status: failed with a message about timeout. You may extend the job info with other fields for granular error conditions as needed. Notably, the exception field is also available. The status field remains simple to facilitate interactions without too much server-specific logic.

[francescoingv]

3. After the 410 Gone is ackknowledged by some entity

@fmigneault Please what do you mean with some entity: a client request; a custom specific operation (possibly a cron check); something else...?

[fmigneault]

@francescoingv
It could be a process of your chosing. Basically, whichever tool, background task or client that you employ to list/retrieve jobs and perform some cleanup. Once the job is accessed to emit a 410, your server could deside to remove that job after validating that artifacts were cleaned up, or it could preserve it in storage and return 410 indefinitely. You could also employ a separate field in the job info response to flag that this cleanup was performed or not. The standard is not enforcing any specific strategy to allow implementation flexibility.