{"version":"2.1.280","anchor":"worker-epoch-parse-bug-fixed-in-registerworker","canonical_anchor":"worker-epoch-parse-bug-fixed-in-registerworker","heading":"worker_epoch parse bug fixed in RegisterWorker","tier":"internal","area":"Daemon","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/worker-epoch-parse-bug-fixed-in-registerworker","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### worker_epoch parse bug fixed in RegisterWorker\n\nFixed a bug where the daemon read a worker's epoch number from the wrong place, producing garbage values\n\n**Unclear.** The finding doesn't say what worker_epoch is used for downstream, so the practical impact of the garbage value is inferred only generally.\n\n**What**\n\nWhen the Claude Code daemon (a background process) registers a worker, it reads back a value called `worker_epoch` from the response. This code was pulling that value from the wrong variable, so it was parsing a value that didn't actually hold the epoch number. This has been fixed so `worker_epoch` is now read from the correct response object.\n\n**Why**\n\nBefore this fix, `worker_epoch` would have come out as `NaN` or some other garbage value instead of the real number, since the code was reading it from the wrong place. That could confuse any logic that depends on tracking a worker's epoch correctly.\n\n- Area: Daemon\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}