Bug: quickfiler-high-confidence-partial-screen-backfill

[drmoisan]

• Work Mode: full-bug

Summary

QuickFiler high-confidence mode stops a scan when the first-batch deadline expires and returns a non-empty partial batch immediately, even though fewer than the current screen's ItemsPerIteration messages qualified and more source messages remain. The regression affects the first screen and subsequent screens.

Environment

• OS/version: Windows 11; live Outlook desktop session
• Python version: n/a (C# / .NET Framework 4.8.1 VSTO add-in)
• Command/flags used: QuickFiler launched with QfSettings.HighConfidenceModeEnabled = true
• Data source or fixture: Outlook folder with sparse messages above the configured confidence threshold; the observed form displayed seven or eight items per screen

Steps to Reproduce

1. Enable QuickFiler high-confidence mode with a threshold that few available messages meet.
2. Launch QuickFiler against a folder where the current form size yields an ItemsPerIteration value of seven or eight.
3. Let the first high-confidence scan evaluate many candidates. In the observed run it scanned nearly 40 messages and accepted one before the deadline expired.
4. Observe that QuickFiler returns and displays that one accepted message instead of continuing until the requested screen count is satisfied or the source is exhausted.
5. File the displayed messages and advance to later screens; the same partial-return behavior can recur.

Expected Behavior

QuickFiler must use the current form's ItemsPerIteration value as the requested high-confidence batch size. It must continue dequeuing, scoring, and discarding below-threshold candidates until it has collected that many qualifying messages or it has genuinely exhausted the available source. This contract must apply to the initial screen and every subsequent screen.

Actual Behavior

QfcStreamingDequeueConfidenceGate.DequeueAsync returns its current accepted list when DefaultFirstBatchDeadline expires, even when accepted.Count is greater than zero but less than quantity and _sourceActive() indicates that more messages remain. The initial QfcHomeController.RunAsync path and later QfcHomeController.IterateQueueAsync path both use deadline-bearing dequeue calls, so either path can surface an undersized screen without source exhaustion.

Logs / Screenshots

• Attached minimal logs or screenshot
• Snippet: observed approximately 40 candidates scanned, one accepted, then an immediate return to a one-item screen

Impact / Severity

• Blocker
• High
• Medium
• Low

High: the mode violates its page-fill contract and can require repeated undersized screens while qualifying messages remain. The behavior affects normal use of high-confidence mode and contradicts the completed issue #233 streaming-backfill acceptance criteria.

Source

From: docs/features/potential/2026-08-25-quickfiler-high-confidence-partial-screen-backfill.md

[drmoisan]

Closing as completed. Delivered via PR #610 (merge commit 507a40a5, "Restore QuickFiler backfill after non-empty deadline expiry"), commit c95f7b2b ("fix(quickfiler): backfill high-confidence results after deadline"), an ancestor of origin/main.

Confirmed directly against origin/main:UtilitiesCS/.../QfcStreamingDequeueConfidenceGate.cs (path resolved via git grep, module docstring cites Issue #424): the dequeue loop now reads while (accepted.Count < quantity) { ... if (elapsed >= deadline && accepted.Count == 0) { ...; return new QfcGateBatch(accepted, QfcDequeueStop.DeadlineExpired, scanned); } ... }. The deadline-expiry early return is now gated on accepted.Count == 0 — i.e. the gate only returns a partial/empty batch early when nothing has been accepted yet. A non-empty but undersized accepted list (the defect's exact symptom — 1 accepted, 40 scanned, deadline hit) no longer triggers an early return; the loop continues dequeuing until quantity is satisfied or _sourceActive() reports source exhaustion (QfcDequeueStop.SourceExhausted). This matches the issue's Expected Behavior precisely: continue dequeuing/scoring/discarding until the requested ItemsPerIteration count is collected or the source is genuinely exhausted, on both the initial and subsequent-screen paths.

PR #610 also adds regression coverage for the initial-screen and subsequent-screen backfill paths plus source-exhaustion, and reports 6,476/6,476 tests passing with confidence-gate coverage at 96.77%.

Verified during a full-repo bug sweep (2026-09-02). No branch or PR remains to ship; this was left open only as bookkeeping.