[kriszyp]

Adds an integration test that drives a real Harper process through drop_table, then a graceful restart or a SIGKILL, then a same-name recreate, and checks that no pre-drop row ever comes back. Refs #1212. It does not close that issue: the offline-peer case was reproduced on a cluster before main gained #2962 and #3119 and needs a harper-pro test to confirm it is fixed.

For the human reviewer

1. Requirement: only the single-node half lands here. The task owner asked for both Dropped table can be resurrected after cluster restart — drop is not a durable, replayable txn-log event #1212 scenarios. The cluster scenarios need replication, which is harper-pro-only, and this run was authorized to push only to HarperFast/harper. So they were run in a scratch harper-pro build and are reported under Verification, not committed. Scenario 2 (a peer offline during the drop) failed on the older main it was run against; main now carries Stamp table generations and keep a durable drop marker so a peer that missed a replicated drop_table cannot bring the table back #2962 and Refuse a peer's retired table generation, and keep newer or node-local tables when a peer drops one #3119 for it, and I did not re-run it. Open question: should the cluster test go into harper-pro to confirm the fix? Saying no to this PR costs little, but core CI would then have no process-level check of a local drop.
2. The kill comes after drop_table returns, not during it. dropTable removes its dropping tombstone and awaits the commit before returning, so this test never reaches completeInterruptedDrop. An interrupted drop is covered only by the unit simulation in unitTests/resources/dropTableGhost.test.js. A fault-injection arm could be added later.
3. The post-restart reads wait on a replay barrier. Boot does not await replayLogs (resources/databases.ts:1201). Before each restart the test writes a barrier row, and after boot it waits until that row is visible. This relies on replay applying one database's log in order. If replay were ever parallelized, the barrier would stop working without any error. The alternative is for boot to expose a replay-complete signal.
4. CI cost. The suite does 13 serial boots, about 19 s locally. Each arm has a 300 s timeout and the suite has none, so slow boots cannot eat into a shared budget.
5. Refs, not Closes. This is a regression test; the fix for the cluster case is Stamp table generations and keep a durable drop marker so a peer that missed a replicated drop_table cannot bring the table back #2962 and Refuse a peer's retired table generation, and keep newer or node-local tables when a peer drops one #3119, which this PR does not touch.

Changes

• integrationTests/database/drop-table-restart-recreate.test.ts: the test matrix is three recreate paths × {graceful, SIGKILL}. The paths are an in-process recreate before the restart (the ghost-table incident flow from fix(schema): atomic table drops, interrupted-drop completion at startup, and create-lock release (ghost tables) #1246), create_table after the restart, and a component schema.graphql recreating the table at boot. Each arm checks a primary scan and a secondary index, then writes one fresh row and restarts again. The restart helper sends SIGKILL directly, because Harper's SIGTERM handler exits immediately and would otherwise race the helper's timer. It also waits on the replay barrier.
• integrationTests/database/drop-table-restart-recreate/config.yaml and integrationTests/database/drop-table-restart-recreate/schema.graphql: the fixture component. It holds the two boot-recreated tables with an indexed n, plus the ReplayBarrier table.

Verification

Test results and the cluster run

End-to-end route: the new integration test. npm run test:integration -- integrationTests/database/drop-table-restart-recreate.test.ts

Build	Result
This branch, core 7c06b8364 (current main), rocksdb-js 2.10.0	6/6 pass, 3 consecutive runs under the default runner; the SIGKILL arms confirm signalCode === 'SIGKILL'
Core before #1246 (17a3f60d2) with rocksdb-js 2.0.0, which predates HarperFast/rocksdb-js#647	4 restart-first arms pass; both in-process arms fail: Invalid column family specified in write batch (the ghost-table signature)
Core before #1246 with rocksdb-js 2.1.0	6/6 pass, so this test pins the binding fix; #1246's core-side hardening stays covered by its unit tests

Cluster run, not in this PR: harper-pro main 505ff332 with core 7c06b8364, 2 nodes, bidirectional, rows written on both.

Scenario	Result
1: dropped on both nodes, graceful restart of both, recreate, restart again	pass: stays dropped, recreate empty on both
1b: same, both nodes SIGKILLed right after the drop	pass
2: B killed, drop_table on A (A reports B failed: ECONNREFUSED), B restarted	fail: A has the table again with 0 rows, B still has 40/40 pre-drop rows
2, continued: both nodes restarted	fail: A 0 rows, B 40; the nodes stay diverged
2c: B down, drop then recreate on A, B rejoins, one new write on B	A holds only the new write; B still has 40 pre-drop rows

Not run locally: the Bun runtime (not installed here), Windows, and the full test:integration:all (CI runs them). prettier, oxlint and tsc -p integrationTests are clean for the changed files.

Rebased onto main at 7c253b96a: the earlier DESIGN.md edits were dropped because main's lifecycle-stamp note supersedes them. The test passes 6/6 on the rebased build.

Planning review: Framing-Verdict: chosen-approach-sound.

Signed: Claude Opus 5.5

Complexity: medium

Release target: v5.4 — new test files only; not on v5.3
Related PRs: #1246 overlaps, 2 others independent

🤖 Generated with Claude Code

Origin — the dispatch brief this PR was written from

LIVE CONVERSATION about #1212.

You are answering a person, in a thread, one turn at a time. Every turn:

1. Read the whole thread in this dispatch file's # Log — it is the conversation so far, and each of your previous turns is in it. Read the PR/issue and the code as needed.
2. Answer the LAST message. Append your answer to # Log as your turn. Prose, not a report: they are talking to you, and a status template is not an answer.
3. Set status: needs-input and stop. The thread stays open; their next message resumes it.

Each turn arrives as ASK (answer it, change nothing) or PERFORM (do it, then say what you did) — the person chose which when they sent it, and the run's own prompt tells you which one this is. Never infer it from the wording: an unrequested commit in the middle of a discussion and a polite description of work that was supposed to happen are the two failures this exists to prevent.

Never mark a PR ready and never merge from this conversation.

_{Dispatch: task chat-issue-harper-1212-kriszyp · queued by unknown · ran by codex/gpt-6.1-sol/xhigh · worker kzyp-xps-1}

_{Review-Coverage: authored=claude; ran=cursor-composer,gemini,codex; adjudicated=domain; declined=cursor-grok,cursor-kimi,cursor-muse,muse; rounds=7; full=2 @ 7c253b9}

_{Review-Attention: skim ~2m (decisions: outcome-only-crash-oracle, redundant-replay-barrier, single-node-scope, replay-proxy-vs-signal, process-level-vs-unit, kill-timing-not-forced) @ 7c253b9}

[github-actions]

Release cherry-pick v5.2: cancelled

Cherry-pick branch cherry-pick/v5.2/pr-2901 was deleted — this PR no longer targets v5.2 (milestone is now v5.3).

[gemini-code-assist]

Code Review

This pull request adds integration tests and updates design documentation to ensure that dropped tables remain dropped across restarts and that same-name recreations start empty. The feedback recommends guarding the after hook in the new test suite to prevent secondary TypeError exceptions from masking setup failures if the before hook fails.

[gemini-code-assist]

In node:test, the after hook is executed even if the before hook fails. If setupHarperWithFixture fails in the before hook, ctx.harper will be undefined, and calling teardownHarper(ctx) will throw a secondary TypeError, masking the original failure. Guard the teardown call with a safety check on ctx.harper.

	after(async () => {
		if (ctx.harper) {
			await teardownHarper(ctx);
		}
	});

References

1. In test teardown hooks (such as after or afterEach), ensure cleanup operations for temporary resources are guarded so they only execute if the resources were successfully initialized. Wrap independent teardown steps in try/finally blocks to guarantee all cleanup executes and to prevent secondary errors from masking the original setup failure.
2. In node:test, after hooks are executed even if a before hook throws an error. Do not duplicate cleanup logic or wrap assertions in try...catch blocks inside before hooks solely to ensure cleanup.

[dawsontoth]

cool!