Bug: storewrapper-dialog-imprecise-for-genuine-failure

[drmoisan]

• Work Mode: full-bug

Summary

StoreWrapperController.Launch (UtilitiesCS/OutlookObjects/Store/StoreWrapperController.cs:119-127) shows the same "not available yet, try again after startup completes" dialog message for every non-Ready readiness state, including a genuine/permanent failure case where retrying will not help. The message is imprecise for that case.

Environment

• OS/version: n/a (UI copy defect)
• Python version: n/a
• Command/flags used: n/a
• Data source or fixture: UtilitiesCS/OutlookObjects/Store/StoreWrapperController.cs

Steps to Reproduce

1. Inspect StoreWrapperController.Launch at StoreWrapperController.cs:119: if (readiness.State != StoreLaunchReadinessState.Ready).
2. Inside that single branch (lines 121-126), MyBox.ShowDialog always shows: "Store settings are not available yet. Please try again after startup completes." (title "Store Settings Unavailable").
3. This branch fires for every non-Ready StoreLaunchReadinessState value, which per the addressed-issue comment at lines 96-100 includes both a transient "not yet loaded" state and a genuine-failure state (Globals.Ol.StoresWrapper populated but permanently unable to resolve, vs. still loading).
4. A user hitting the genuine-failure case sees the same "try again after startup completes" copy as a user hitting the transient case, even though retrying will not resolve a genuine failure.

Expected Behavior

The dialog copy should distinguish a transient "still starting up, try again shortly" case from a genuine/permanent failure case, so users are not told to retry when retrying cannot help.

Actual Behavior

Both cases produce the identical message: "Store settings are not available yet. Please try again after startup completes."

Logs / Screenshots

• Attached minimal logs or screenshot
• Snippet: Confirmed directly against source at UtilitiesCS/OutlookObjects/Store/StoreWrapperController.cs:119-127. Explicitly flagged as a known, deliberately-deferred follow-up in docs/features/active/2026-07-07-folder-settings-store-model-null-262/spec.md:60-62: "Changing the StoreWrapperController 'not available yet' dialog copy for the genuine-failure case (imprecise but not required by any AC; documented follow-up only)." That feature (part of the now-merged epic Epic: store-lockup-resilience #260, store-lockup-resilience) intentionally left this out of scope. No open GitHub issue currently references this dialog copy (verified via gh issue list).

Impact / Severity

• Blocker
• High
• Medium
• Low

Cosmetic/messaging-accuracy issue only; no functional or data-integrity impact. Confusing but not blocking, since the dialog still prevents the user from proceeding into a non-ready settings dialog either way.

Source

From: docs/features/potential/2026-07-09-storewrapper-dialog-imprecise-for-genuine-failure.md