Function publish_pid 

async fn publish_pid(
    client: &WpsClient,
    tool_id: &str,
    block_id: Option<&str>,
    pid: u32,
)

Publish this process’s own pid, once, for a declared-background invocation. Called via tokio::spawn (never awaited inline) — see the call site’s comment for why blocking startup on this was a real latency bug (reagentx P1, PR #2681).

The single retry here is insurance against a transient MPS/HTTP publish failure ONLY — it does not, and cannot, wait for db_background_tasks’s row to exist first (this function has no visibility into srv’s database state). This publish routinely arrives at srv before that row exists at all (this call fires at process start, before the frontend has even seen an accepted-background tool result to create the row from) — that ordering race is handled entirely server-side, by stashing an early pid and applying it once the row is created (pending_background_pids.rs, websocket.rs’s COMMAND_BACKGROUND_TASK_PID/COMMAND_DOCK_NODE_STATUS handlers). An earlier version of this comment claimed this retry covered that race — it never did (Codex P1, reagentx P2, PR #2681).