[mremond]

Why

A supervisor restarting a child must not race deletion of the child's named ETS table.

What changed

• Native process exits delete owned ETS tables before delivering linked EXIT or monitored DOWN signals.
• The same ordering covers linked-exit cascades, allowing immediate named-table recreation.

Before and after

Before: The new fixture failed all ten runs on the unchanged native runtime when immediate table recreation raised badarg.

After: The fixture passes ten runs with default native schedulers, ten with one scheduler, and ten on OTP 29.1.2.

This changes runtime exit ordering, which has no visible screen.

Checked

Live validation: Demonstrated for this version. 3 of 4 scenarios driven live in the product.

Scenario	Result	Evidence
Immediate named-table recreation after five native exit paths and 100 supervised restarts per run.	✅ Passed live	Twenty complete native runs: ten default-scheduler and ten single-scheduler, with zero exit statuses and both completion markers.
Run the identical Erlang fixture on the reference runtime.	✅ Passed live	Ten completed runs on OTP 29.1.2; the fixture hash remains unchanged after integration updates.
Check deletion before held DOWN delivery for direct and cascading exits, including unnamed tables and ownership isolation. (supplementary)	⏸ Supporting evidence	The corrected negative control fails before the fix; both supporting unit tests pass ten consecutive runs.
Run the complete local gate and prescribed runtime shutdown journey.	✅ Passed live	2,185 Rust passes, one ignored; 495 native passes, two expected skips; builds, lint, allocator, stacktrace and all 300 shutdown samples pass.

• Independent review: The change, both integrations with newer runtime work and the completed validation evidence passed review without actionable findings.

How it was checked

cargo build --release --locked -p nera-runtime, then -p nera, then the workspace

cargo clippy --workspace --all-targets --locked -- -D warnings

cargo test --workspace --locked --no-fail-fast

python3 scripts/test-allocator-config.py

./target/release/nera test -j 1 --timeout 30

python3 scripts/test-stacktrace-order.py

python3 scripts/test-native-shutdown.py: largest median 1.16 ms, below the prescribed 5 ms limit; maximum sample 11.24 ms, with no maximum-latency guarantee

Ten consecutive runs each of exit_deletes_ets_before_any_signal and owner_exit_releases_only_its_named_table

The unchanged ets_freed_before_signal fixture ran ten times per engine/scheduler mode with explicit fixture and return completion markers

Risk

Risk above low: Blast radius, medium — All native exit paths share this scheduler cleanup phase.

Full risk assessment

Dimension	Level	Why
Blast radius	medium	All native exit paths share this scheduler cleanup phase.
Behavior	low	Corrects table deletion ordering without changing ETS operations.
Undo	low	Reverting restores the previous cleanup order; no stored data migration.
Evidence	low	Actual programs reproduce failure before the fix and complete natively and on BEAM after it.
Sensitivity	low	No accounts, credentials, persistent settings or release changes.
Novelty	low	Moves existing cleanup into the established shared exit phase.
Dependencies	low	No dependency changes.

Not done

ETS heir support is outside this deletion-order change.

Pipeline

Updates from git push no-mistakes

Infinitary checked this version: an independent review that also judged the documents, and live validation the review accepted.