Bug: emailmovemonitor-rejected-item-hook-retention

[drmoisan]

• Work Mode: full-bug

Summary

Mail items that the QuickFiler high-confidence dequeue gate scores and rejects are removed from the master queue but are never unhooked from EmailMoveMonitor. Each retained entry holds a live MailItem COM reference and participates in a Folder.BeforeItemMove subscription until session cleanup, so COM-reference retention grows in proportion to the number of rejected candidates.

Environment

• OS/version: Windows 11 Pro 10.0.26200
• Runtime: C# / .NET Framework 4.8.1 VSTO add-in (no Python involvement)
• Command/flags used: QuickFiler launched from the TaskMaster ribbon with QfSettings.HighConfidenceModeEnabled = true
• Data source or fixture: Live Outlook mailbox with a realistic message volume and a low fraction of items above HighConfidenceThreshold

Steps to Reproduce

1. Enable High Confidence mode and launch QuickFiler against a folder where most messages score below the threshold.
2. Let the dequeue gate scan and reject a large number of candidates while assembling the first batch.
3. Inspect EmailMoveMonitor._hookedItems (or observe process COM-reference growth) while the QuickFiler session remains open.

Expected Behavior

An item removed from the master queue is unhooked from the move monitor regardless of whether the gate accepted or rejected it, so _hookedItems tracks only items still under management.

Actual Behavior

Only accepted items are unhooked. _hookedItems accumulates one EmailMoveAction per rejected candidate for the life of the session, each holding a live MailItem COM reference. If such a mail is moved while QuickFiler is open, the retained hook action fires _masterQueue.Remove(x) for an item no longer in the queue - a no-op removal, but evidence that the stale hook is still live.

Logs / Screenshots

• Attached minimal logs or screenshot
• Snippet: not captured. The defect was found by static analysis during the issue Bug: quickfiler-high-confidence-queue-init-stall #424 investigation, not from a runtime report.

Impact / Severity

• Blocker
• High
• Medium
• Low

Medium: no data loss or incorrect filing. The cost is session-scoped unmanaged-resource retention and a set of live event subscriptions that outlive their purpose. Everything is released at Cleanup(). Severity rises with the volume of rejected candidates, so the issue #424 fix - which makes high-confidence scanning practical and therefore more heavily used - increases exposure rather than reducing it.

Source

From: docs/features/potential/2026-08-07-emailmovemonitor-rejected-item-hook-retention.md

[drmoisan]

Closing as completed. Delivered under the sibling family feature quickfiler-bug-family-446, commit 2281921d ("fix(446): report a dequeue stop reason, release rejected hooks, carry top folder to the datamodel boundary"), merged via PR #625 (via the epic integration branch, hence no auto-close), an ancestor of origin/main.

Confirmed directly against origin/main: QfcDatamodel.QueueProcessing.cs now wires onRejected: TryReleaseRejectedHook into QfcStreamingDequeueConfidenceGate, which invokes it (_onRejected?.Invoke(mailItem)) for every rejected candidate — releasing the EmailMoveMonitor hook regardless of whether the gate accepted or rejected the item, rather than only on acceptance.

The delivering spec's AC4 (gate test) and #426 datamodel-wiring AC are both checked [x], with dedicated regression tests (DequeueAsync_BelowThresholdCandidate_InvokesOnRejectedOnce, DequeueNextItemGroupAsync_HighConfidenceRejectedItem_UnhooksFromMoveMonitor).

Note: this is distinct from the closely related issue #427, which the same feature deliberately left partially delivered (producer-side only) and which must remain open — its consumer-side residual was promoted to #678.

Verified during an admission check against the bugs-638-644-647 parallel run (2026-09-01). No branch or PR remains to ship; this was left open only as bookkeeping.