WSUS updates stuck in NotReady state after offline metadata + content import on an air-gapped server

Context

I'm automating the transfer of Microsoft updates between two isolated networks. Each network has its own WSUS server:

• a source server, connected to the internet, which receives and auto-approves updates;
• a target server, fully air-gapped, with no network link to the source server.

Because there is no direct path between the two servers, updates have to be exported from the source and re-imported on the target out-of-band. On the target server, my import process does two things:

1. Imports the update metadata using the wsusutil import command (taking the compressed XML export plus a log file path as arguments). The compressed XML export is produced on the source server by a custom script that builds a wsusutil-import-compatible archive containing the metadata of a specific set of updates.
2. Copies the corresponding binary files into the WsusContent folder of the target server.

Problem

After the import, the metadata is correctly present (the updates show up in the WSUS console) and the binary files are physically present in the WsusContent folder. However, the affected updates stay in the NotReady state when queried through the WSUS API, and the WSUS console displays them as "Downloading" — even though nothing is actually downloading and the files are already on disk.

What I tried

I wrote a routine that reconciles the ActualState column of the tbFileOnServer table in SUSDB against the files actually present on disk, so that each file record reflects that its binary is present on the server. Despite this, the updates are still reported as NotReady by the API and as "Downloading" in the console. So directly editing the ActualState column of tbFileOnServer does not seem to be enough on its own.

Questions

1. Is the ActualState column of tbFileOnServer the wrong place to act? Is the per-update readiness state cached or computed somewhere else (another table such as tbFileForRevision or tbRevision, a stored procedure, or a cache held by the WSUS service) that I also need to refresh?
2. Is there a supported mechanism — a wsusutil command or a WSUS API method — that forces WSUS to re-scan the WsusContent folder and reconcile the download/readiness state of updates against the files actually present on disk?
3. I considered the wsusutil reset command, but I'm unsure how it behaves on an air-gapped server: would it correctly mark the already-present files as available, or would it queue (failing) downloads for every file because it can't reach Microsoft Update?
4. Does this state get cached at the service level — i.e. is a WSUS or IIS service restart, or some cache-invalidation step, required for the API and console to reflect the updated state?

Environment

• WSUS role on Windows Server [version, ex. 2022 / 2025]
• SUSDB hosted on WID
• Updates approved automatically on the source side; target side is offline.