meta: a resource that comes back gets a fresh drop clock

[bjmeetsfo]

A resource that comes back keeps the clock from the last time it left

stamp_dropped_since keeps the first time it is given:

// Keep the first drop time: re-dropping an already dropped resource
// must not restart its retention clock.
state.dropped_since_ms.entry(key.to_string()).or_insert(now_ms);

That is right for drop-then-drop. It is wrong across a revival, and re-registration never cleared the entry — so the tombstone outlived the drop it recorded.

The consequence shows up on the second drop, which is where nobody looks:

1. node-a is dropped in January. Clock stamped.
2. node-a comes back an hour later and serves for six months.
3. node-a is dropped again in July.
4. Retention reads the January stamp, computes an age of six months, and collects it on the next round — with none of the grace the retention window exists to give.

The grace period is what lets a node that comes back keep its identity. Here it was already spent.

The fix

Re-registering a server or a proxy clears its drop clock, so the next drop starts a fresh one. Four lines across the two registration paths.

The other direction still holds and is pinned by its own test: repeatedly dropping an already dropped server cannot hold off collection.

A test that did not test its own name

a_resource_that_comes_back_loses_its_tombstone_clock asserted only that the revived server was not collected. That was already guaranteed by the candidate filter, which requires state Dropped — the assertion passed with the clock untouched. It now checks the clock, which is what its name claims.

Tests

4 new plus that strengthened one. Two of the new ones fail on main:

test a_server_that_comes_back_starts_a_fresh_drop_clock ... FAILED
test a_proxy_that_comes_back_starts_a_fresh_drop_clock  ... FAILED

The other two are the consequence (a revived server dropped again is not immediately eligible) and the guard (re-dropping without a revival still keeps the first clock).

Verification:

• cargo test -p temporalstore-rust --lib meta -- --test-threads=1 — 256 passed, 0 failed.
• cargo check -p temporalstore-rust --all-targets — clean.

Retention GC is off by default, so this changes nothing until it is switched on. It is worth fixing anyway: the wrong value is being recorded now, and it is recorded into snapshots that outlive the setting.