“File does not exist” After Successful Sync + Repair Task Stuck in Waiting (pulpcore 3.95.3)

Support
#1

Hi all,

We are running pulpcore 3.95.3.

A repository sync initially completed successfully. However, when attempting to re-sync the repository, we encountered the following error:

File does not exist: artifact/42/851c1e14af0fad2f6f96949b5b0763c8e8e5e58bb712070550aa8eda1ad8ed

This suggests that the artifact metadata exists in the database, but the underlying file is missing from storage.

After that, I attempted to run a repair operation. The repair task is now stuck in the “waiting” state and never starts.

Below is the task detail:

{
“pulp_href”: “/pulp/api/v3/tasks/019c7c94-ef69-76dc-a3ba-97864ba09e3a/”,
“state”: “waiting”,
“name”: “pulpcore.app.tasks.repository.repair_all_artifacts”,
“reserved_resources_record”: [
“pdrn:6a9404ae-dfee-4099-b62d-8820e889c5bb:repair”,
“shared:prn:core.domain:6a9404ae-dfee-4099-b62d-8820e889c5bb”
],
“worker”: null,
“started_at”: null,
“error”: null
}

Worker Status

Output of pulp worker list:

[
{
“pulp_href”: “/pulp/api/v3/workers/019c4419-fde3-7001-b60d-ce4a68c79a73/”,
“prn”: “prn:core.appstatus:019c4419-fde3-7001-b60d-ce4a68c79a73”,
“pulp_created”: “2026-02-09T20:31:20.037536Z”,
“pulp_last_updated”: “2026-02-09T20:31:20.037554Z”,
“name”: “1@875ff6862b63”,
“last_heartbeat”: “2026-02-19T11:57:41.740805Z”,
“versions”: {
“deb”: “3.8.0”,
“rpm”: “3.34.0”,
“core”: “3.95.3”,
“file”: “3.95.3”,
“ostree”: “2.6.0”,
“certguard”: “3.95.3”
},
“current_task”: null
},
{
“pulp_href”: “/pulp/api/v3/workers/019c4419-df13-75d1-8269-1a9b05cad32f/”,
“prn”: “prn:core.appstatus:019c4419-df13-75d1-8269-1a9b05cad32f”,
“pulp_created”: “2026-02-09T20:31:12.149995Z”,
“pulp_last_updated”: “2026-02-09T20:31:12.150017Z”,
“name”: “1@89519b7d84bb”,
“last_heartbeat”: “2026-02-19T11:57:41.863198Z”,
“versions”: {
“deb”: “3.8.0”,
“rpm”: “3.34.0”,
“core”: “3.95.3”,
“file”: “3.95.3”,
“ostree”: “2.6.0”,
“certguard”: “3.95.3”
},
“current_task”: null
},
{
“pulp_href”: “/pulp/api/v3/workers/019c4419-bd8a-714b-947f-347601daa2e0/”,
“prn”: “prn:core.appstatus:019c4419-bd8a-714b-947f-347601daa2e0”,
“pulp_created”: “2026-02-09T20:31:03.564460Z”,
“pulp_last_updated”: “2026-02-09T20:31:03.564478Z”,
“name”: “1@fb79a47b6026”,
“last_heartbeat”: “2026-02-19T11:57:41.387865Z”,
“versions”: {
“deb”: “3.8.0”,
“rpm”: “3.34.0”,
“core”: “3.95.3”,
“file”: “3.95.3”,
“ostree”: “2.6.0”,
“certguard”: “3.95.3”
},
“current_task”: null
}
]

Questions

  1. What could cause artifacts to exist in the database but be missing from storage?
  2. What is the recommended way to recover from this state?
  3. Why would the repair_all_artifacts task remain indefinitely in waiting state with no worker assigned?

Any guidance on how to properly recover without rebuilding everything from scratch would be greatly appreciated.