Bug: quickfiler-high-confidence-queue-init-stall

[drmoisan]

• Work Mode: full-bug

Summary

When QuickFiler runs with High Confidence mode enabled, the ProgressViewer stops at "Initializing Email Queue" for an extended period before the first QuickFiler screen appears. The same startup in normal mode presents its first screen promptly.

Environment

• OS/version: Windows 11 Pro 10.0.26200
• Python version: n/a (C# / .NET Framework VSTO add-in)
• Command/flags used: QuickFiler launched from the TaskMaster ribbon with QfSettings.HighConfidenceModeEnabled = true
• Data source or fixture: Live Outlook mailbox; the configured QuickFiler source folder with a real message volume

Steps to Reproduce

1. Enable High Confidence mode in QuickFiler settings (HighConfidenceModeEnabled = true, HighConfidenceThreshold at its configured value).
2. Launch QuickFiler against a mailbox folder containing a realistic number of messages.
3. Observe the ProgressViewer.

Expected Behavior

The first QuickFiler screen appears within a short, bounded time. Progress reporting advances or otherwise reflects ongoing work, and the pre-UI wait does not grow without limit as the proportion of high-confidence items falls.

Actual Behavior

The ProgressViewer displays "Initializing Email Queue" and stays there for an extended time. Progress remains at 0 for the entire wait; the label only changes once the full first batch of high-confidence items has been assembled.

Logs / Screenshots

• Attached minimal logs or screenshot
• Snippet: the log4net "Probability debug [QfcStreamingDequeueConfidenceGate.DequeueAsync]" lines emit one entry per scored candidate during the stall.

Impact / Severity

• Blocker
• High
• Medium
• Low

High: the feature remains functional but the startup latency in High Confidence mode makes the mode impractical for routine use.

Source

From: docs/features/potential/2026-08-06-quickfiler-high-confidence-queue-init-stall.md

[drmoisan]

Delivered by #425 (merged 2026-08-07, merge commit 6b63850). The PR body did not use a closing keyword, so this issue was not auto-closed.

Verified against origin/main:

• QuickFiler/Controllers/QfcStreamingDequeueConfidenceGate.cs carries a TimeProvider-based DefaultFirstBatchDeadline of 12 s and an optional per-candidate progressCallback, with Timeout.InfiniteTimeSpan as the disable sentinel.
• QuickFiler/Controllers/QfcScanProgressBandMapper.cs is present and maps gate scan progress into the RunAsync 0-30 band.
• The pre-UI empty-queue poll was reduced to 200 ms and the _worker.IsBusy producer-liveness signal was replaced with a datamodel-owned volatile bool.

Expected behavior in this issue (bounded first-screen wait, progress that advances during the scan) is satisfied. Follow-up defects found during this investigation are tracked separately in #426 and #427.

Closing as delivered.