HarperFast / HarperFast/harper-pro

A same-name URL migration leaves an armed recovery timer that can force-reconnect the address the node left

Open
#806 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

Found by a full cross-model re-read of [#800](https://github.com/HarperFast/harper-pro/pull/800) (branch `fix/replication-uniform-backoff`), recorded in that PR's description and deliberately not fixed there. **The armed-timer half is unmerged code**; the entry leak underneath it is on `main`.

## What is wrong

When a node keeps its name but moves to a new URL, the reconciliation path cancels the *setup scheduler* for the old URL and knowingly leaves the old `connectionReplicationMap` entry behind:

```js
// A node that moved to a new URL leaves its old URL's entry behind (pre-existing); at least do
// not let a setup armed for the address it left fire against it.
const previousUrl = previousNode && getNodeURL(previousNode);
if (previousUrl && previousUrl !== getNodeURL(node)) subscribeSetupScheduler.cancelUrl(previousUrl);
```

That was a sound scoping decision when the only armed work for a URL was a setup. #800 adds an **owned per-entry recovery timer** (`entry.reDriveTimer`), and the stale entry survives the migration with its ownership guards intact — so an already-armed recovery timer can still fire and post a force-reconnect to the endpoint the node has left.

Old leak, new consequence: the entry surviving is pre-existing, the timer riding on it is not.

## Why this epic

This is the same class as the interaction bug this workstream already records — the #466 false-positive force-reconnect in the wedge re-drive. Each recovery layer is individually correct; the defect is one layer holding a reference the other layer's teardown does not clear.

## The shape of a fix

Either migrate or tear down the old URL's entry on a same-name URL change — its iterator, worker subscription and recovery timer — or, minimally, clear every old entry's `reDriveTimer` alongside the existing `cancelUrl`. Worth covering with a test that changes a node's URL while a recovery timer is armed.

Refs #800, #466

Contributor guide

Open the contributing guide

Research direction

Start by tracing the reconciliation path around connectionReplicationMap and subscribeSetupScheduler.cancelUrl, then inspect the per-entry reDriveTimer ownership and teardown. Reproduce a same-name node URL change while recovery is armed. Done means the old URL cannot trigger a force-reconnect, with a regression test covering that migration.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, nodejs
Domain
distributed-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.