fix: register operations in worker threads so replication WS can dispatch them - #523
Merged
Merged
Conversation
…atch them After 40600bf moved the HTTP operations API to the main thread only, `server.registerOperation` was no longer wired up in worker threads. Plugins that call `server.registerOperation?.({...})` at module load time (e.g. replication's setNode.ts, clusterStatus.ts) silently no-op'd in workers because the optional-chain short-circuits when the method is undefined. This breaks inter-node replication setup: `add_node` opens a WebSocket to the target node's replication port (9933) and sends `add_node_back`. The WS handler runs in a worker thread and dispatches via `server.operation()`, which looks up in the operation function map. Since `add_node_back` was never registered in the worker, every cluster setup attempt fails with: "Operation 'add_node_back' not found and connection was required to sign certificate" This blocks `fullyConnectedReplication.test.mjs`, `replicationLoad.test.mjs`, and anything else that exercises multi-node clustering. Fix: in worker threads, eagerly require `serverHelpers/serverUtilities` directly, which installs `server.operation`, `server.registerOperation`, and initializes the operation function map without binding the fastify HTTP layer (that stays main-thread-only per the original change). Verified by re-running `fullyConnectedReplication.test.mjs` — 12/12 pass (6 RocksDB + 6 LMDB). `replicationLoad.test.mjs` `connect nodes` and `Deploy app and test replication` now pass; remaining failures (`replicate across many databases`, `replicate insert/upsert across all nodes`) are unrelated concurrency / many-database issues. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>
Contributor
|
Reviewed; no blockers found. |
cb1kenobi
approved these changes
May 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Re-enable
server.registerOperationand the operation function map in worker threads so plugin operations (e.g. replication'sadd_node_back) are actually registered. After 40600bf moved the HTTP operations API to main-thread-only,server.registerOperationwas no longer set up in worker threads — module-level calls likeserver.registerOperation?.({...})insetNode.tssilently no-op'd because the optional-chain short-circuits when the method is undefined.This broke inter-node cluster setup.
add_nodeopens a WebSocket to the target node's replication port (9933) and sendsadd_node_back. The WS handler runs in a worker thread and dispatches viaserver.operation(), which looks up in the operation function map. Sinceadd_node_backwas never registered in the worker, every cluster setup attempt fails with:This blocks
fullyConnectedReplication.test.mjs,replicationLoad.test.mjs, and anything else exercising multi-node clustering.Fix
In
components/componentLoader.ts, when not on the main thread, eagerly requireserverHelpers/serverUtilities(which installsserver.operation,server.registerOperation, and initializes the operation function map). This does NOT load the fastify HTTP layer — that stays main-thread-only per 40600bf.Verification
Verified locally:
fullyConnectedReplication.test.mjs— 12/12 pass (6 RocksDB + 6 LMDB; previously 0/12).replicationLoad.test.mjsconnect nodesandDeploy app and test replicationnow pass; remaining failures are unrelated concurrency / many-database issues.issue135-replicated-search-after-restart.test.mjsin harper-pro (Scenario B) now runs successfully.Review attention
The conditional require approach mirrors the existing main-thread-only operationsServer require. It's a minimal change but the failure mode (silent no-op via
?.) is exactly the same class of issue, so the same fix shape should be considered for any future plugin that usesserver.registerOperationfrom a worker-loaded module.🤖 Generated with Claude Sonnet 4.6 (1M context)