[P0] Registry destruction does not reclaim loader state despite merged #133 #156

New issue

Closed

opened 2026-08-21 22:20:15 +00:00 by lost-rob0t · 1 comment

lost-rob0t commented

2026-08-21 22:20:15 +00:00

(Migrated from github.com)

Regression

The restored aggregate PlUnit gate from #151/#152 executes the previously skipped rlm_tool_loader tests and proves the merged #133/#67 cleanup claim is false on the repository CI runtime.

Observed failures include:

destroy_reclaims_loader_idempotency_state_automatically: loaded_tool_pack/4 rows remain after tool_registry_destroy/1;
destroy_cleanup_is_scoped_to_the_destroyed_registry: destroyed-registry rows remain;
repeated_registry_churn_does_not_retain_loader_state: 64 retained rows instead of 0.

Current implementation

rlm_tool_loader relies on:

prolog_listen(rlm_tool:tool_registry_alive/1,
              registry_lifecycle_event,
              [name(rlm_tool_loader_registry_cleanup)]).

and attempts to infer completed retractall/1 lifecycle events. The real SWI 9.0.4 CI execution does not satisfy the assumed callback contract here, so registry-owned loader state leaks.

Required fix

Replace the fragile listener trick with an explicit generic registry-destroy hook owned by rlm_tool, while preserving dependency direction:

rlm_tool owns registry lifecycle
  -> invokes trusted multifile destroy hooks
  -> rlm_tool_loader contributes cleanup hook when loaded

Core must not import the loader. Hook failure must not leave the core registry alive, and cleanup must remain idempotent.

Acceptance

ordinary tool_registry_destroy/1 automatically removes all loaded_tool_pack/4 rows for that registry;
cleanup is scoped to only the destroyed registry;
repeated create/load/destroy churn retains zero loader rows;
destroying a registry that never used the loader remains valid;
destroy-vs-late-loader-return race still cannot resurrect bookkeeping;
no rlm_tool -> rlm_tool_loader import/circular business dependency;
restored aggregate test/run_tests.pl is the merge oracle;
do not weaken or remove the existing #67 regressions.

Discovered during post-false-green remediation after #60.

## Regression The restored aggregate PlUnit gate from #151/#152 executes the previously skipped `rlm_tool_loader` tests and proves the merged #133/#67 cleanup claim is false on the repository CI runtime. Observed failures include: - `destroy_reclaims_loader_idempotency_state_automatically`: `loaded_tool_pack/4` rows remain after `tool_registry_destroy/1`; - `destroy_cleanup_is_scoped_to_the_destroyed_registry`: destroyed-registry rows remain; - `repeated_registry_churn_does_not_retain_loader_state`: 64 retained rows instead of 0. ## Current implementation `rlm_tool_loader` relies on: ```prolog prolog_listen(rlm_tool:tool_registry_alive/1, registry_lifecycle_event, [name(rlm_tool_loader_registry_cleanup)]). ``` and attempts to infer completed `retractall/1` lifecycle events. The real SWI 9.0.4 CI execution does not satisfy the assumed callback contract here, so registry-owned loader state leaks. ## Required fix Replace the fragile listener trick with an explicit generic registry-destroy hook owned by `rlm_tool`, while preserving dependency direction: ```text rlm_tool owns registry lifecycle -> invokes trusted multifile destroy hooks -> rlm_tool_loader contributes cleanup hook when loaded ``` Core must not import the loader. Hook failure must not leave the core registry alive, and cleanup must remain idempotent. ## Acceptance - [ ] ordinary `tool_registry_destroy/1` automatically removes all `loaded_tool_pack/4` rows for that registry; - [ ] cleanup is scoped to only the destroyed registry; - [ ] repeated create/load/destroy churn retains zero loader rows; - [ ] destroying a registry that never used the loader remains valid; - [ ] destroy-vs-late-loader-return race still cannot resurrect bookkeeping; - [ ] no `rlm_tool -> rlm_tool_loader` import/circular business dependency; - [ ] restored aggregate `test/run_tests.pl` is the merge oracle; - [ ] do not weaken or remove the existing #67 regressions. Discovered during post-false-green remediation after #60.

lost-rob0t commented

2026-08-24 08:06:42 +00:00

(Migrated from github.com)

Completed on current main through the explicit generic registry-destroy hook integrated in #177. Focused lifecycle/security verification passed 24/24 and source inspection confirms dependency direction remains rlm_tool_loader -> rlm_tool only. PR #157 was closed as superseded.