Repository navigation
Bug: quickfiler-emailmovemonitor-instances-not-shared #620
Description
Activity
The promotion tool maps only a subset of the potential-entry headings into the issue body;
## Suspected Cause / Notesand## Proposed Fix / Validation Ideaswere dropped. Restoring them here so the provenance and the remediation ideas are not lost.Suspected Cause / Notes
Discovered during issue #446 (
docs/features/active/quickfiler-bug-family-446). Out of scope there: #446 fixed the datamodel's own unhook path by calling its own monitor directly, which is correct but does not consolidate the instances. Consolidating ownership is a separate cross-cutting change to three files that were not in #446's owned set.Proposed Fix / Validation Ideas
- Establish a single shared
EmailMoveMonitor(constructor injection or a shared owner) consumed by all three collaborators - Unit coverage asserting a hook registered via one collaborator is released by an unhook routed through another
- Verify no double-unhook or double-dispose is introduced by the consolidation
- Establish a single shared
- added a commit that references this issue
on Sep 2, 2026
Summary
UnhookItemcan never release a hook thatQfcDatamodelregistered, because three collaborators each construct their own independentEmailMoveMonitorrather than sharing one.QuickFiler/Controllers/QfcDatamodel.cs:103,QuickFiler/Controllers/QfcQueue.cs:40andQuickFiler/Controllers/QfcCollectionController.cs:78each build a separate instance, so theUnhookItemcall atQuickFiler/Controllers/QfcQueue.cs:76consults a hook list that structurally cannot contain the datamodel's registrations. Any unhook routed throughQfcQueueis therefore a silent no-op against datamodel-registered items, and the monitor retains those hooks for the life of the object.Environment
Steps to Reproduce
QfcDatamodel, which uses the monitor constructed atQuickFiler/Controllers/QfcDatamodel.cs:103.QfcQueue, which callsUnhookItematQuickFiler/Controllers/QfcQueue.cs:76against the distinct monitor constructed atQuickFiler/Controllers/QfcQueue.cs:40.Expected Behavior
The unhook releases the item, whichever collaborator registered it.
Actual Behavior
The unhook is a no-op. The two monitors are separate objects with separate hook lists, so the lookup cannot match.
Logs / Screenshots
Impact / Severity
Correctness and lifetime issue rather than a crash. Hooks accumulate and are never released through this path.
Source
From: docs/features/potential/2026-08-26-quickfiler-emailmovemonitor-instances-not-shared.md