HarperFast / HarperFast/harper-pro
add_node_back does not rewrite peer-qualified sendsTo/receivesFrom entries
- Dominant language
- JavaScript
- Stars
- 3
- Forks
- 0
- Avg merge
- 1d 21h
- Merged PRs (30d)
- 80
Description
## Summary
`add_node` accepts `sendsTo` / `receivesFrom` entries and registers the reciprocal node record through `add_node_back`. The reciprocal request swaps the two arrays, but it does not rewrite peer-qualified entries for the opposite side of the connection.
As a result, bare peer-name strings and entries with `target` / `source` can authorize the local record but silently fail on the reciprocal record. The remote node then rejects or never attempts the expected subscription. Only entries that omit the peer qualifier, such as `{ database: "system" }`, work reliably in both records.
## Root cause
In `replication/setNode.ts`, `setNode()` constructs the reciprocal request as:
```ts
targetAddNodeObj.sendsTo = req.receivesFrom;
targetAddNodeObj.receivesFrom = req.sendsTo;
```
Swapping the arrays reverses the direction, but the entries retain the peer name from the original node's perspective. For example, a `receivesFrom` entry qualified with `source: "node-a"` becomes a `sendsTo` entry on node B that still names node A, where the corresponding target should be node B. Bare strings have the same perspective problem because they name a peer.
## Impact
An `add_node` or `set_node` request can succeed while the requested directional replication does not. This is especially hard to diagnose because unqualified database-scoped entries work, while adding a peer qualifier changes the behavior without producing an operation error.
The limitation is documented in [documentation PR #583](https://github.com/HarperFast/documentation/pull/583), but the warning needs this issue as its owner and retirement condition.
## Expected behavior
The reciprocal registration should rewrite peer-qualified entries for the receiving node's perspective, or reject unsupported forms explicitly instead of accepting a configuration that cannot authorize replication.
## Acceptance criteria
- `add_node` / `set_node` correctly reverse bare-string and `target` / `source` peer qualifiers in the reciprocal `add_node_back` request, or reject those forms with a clear validation error.
- Integration coverage verifies both local and reciprocal records for `sendsTo` / `receivesFrom` entries.
- Documentation PR #583's warning can be removed or narrowed after the fix ships.
Contributor guide
Research direction
Start in replication/setNode.ts and trace setNode() through the reciprocal add_node_back request, comparing bare strings with target/source and source/target qualifiers. Add integration coverage for both local and reciprocal sendsTo/receivesFrom records, and verify that documentation PR #583's warning can be removed or narrowed once the behavior is fixed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- nodejs, typescript
- Domain
- databases, distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100