[BUG] Corrective task registration does not restore failed-replay worker readiness #199

Duplicate issue

• Existing issues checked. Shared upstream defect: [BUG] Successful corrective registration leaves a failed-replay worker unready poolifier#3367.

Description

After a runtime-function replay fails, a successful corrective add installs the valid function on the same live worker but never makes that worker selectable again.

Steps to reproduce

On PR #196, use a normal ThreadWorker({ stock: x => x + 1 }) entrypoint:

const pool = new FixedThreadPool(1, workerURL, { startWorkers: false })
const failed = Promise.withResolvers()
pool.eventTarget.addEventListener('error', e => failed.resolve(e.error), { once: true })
const initial = x => x + 1
initial.toString = () => 'null'
await pool.addTaskFunction('recover', initial) // true with no workers
pool.start()
await failed.promise // genuine replay-validation failure
await pool.addTaskFunction('recover', x => x + 1) // true
await pool.execute(42, 'recover') // rejects

Catch rejection and destroy in finally. The toString override deliberately injects invalid serialized code; no fabricated ACKs/events or mutation of readiness.

Expected / actual behavior

Correction should permit full state restoration before readiness. Instead, on both runtimes, corrective add returns true and an observation-only real worker round trip confirms the new function returns 43, but the same worker remains unready. Public execution rejects with Worker node key chosen by LEAST_USED is null or undefined after 2 retries (max: 2). No-fault controls execute 43; bounded destruction succeeds.

Versions and exact scope

Reproduced at PR head 2310e5233275a194045fe1a71b11971c427dc784, Deno 2.9.7 and Bun 1.4.2, Linux x64. PR-only bootstrap path, not this exact bug on current port master b246ef37ae59a591686df92a135f8d53f595d8e7: that baseline does not replay preregistrations to fixed workers, stays ready, and executes after corrective add. The baseline's older missing-replay behavior is distinct.

Also reproduced on canonical upstream master 0104449a0a01f252dc9bec8f36164134f3bbe89f, Node v26.11.1 threads and cluster. Browser not tested.

Cause / fix constraint

Failed replay skips readiness restoration and deletes its bootstrap; corrective add does not restart it. Preserve recoverable failure state separately from active waits, then retry complete replay/default setup after correction. Do not mark ready after only one ACK or retain a rejected active wait that blocks correction.

Review: #196 (comment).