HarperFast / HarperFast/harper-pro

add_node_back does not rewrite peer-qualified sendsTo/receivesFrom entries

Open
#710 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.