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
- Inspect
StoreWrapperController.Launch at StoreWrapperController.cs:119: if (readiness.State != StoreLaunchReadinessState.Ready).
- 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").
- 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).
- 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
Impact / Severity
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
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-Readyreadiness state, including a genuine/permanent failure case where retrying will not help. The message is imprecise for that case.Environment
UtilitiesCS/OutlookObjects/Store/StoreWrapperController.csSteps to Reproduce
StoreWrapperController.LaunchatStoreWrapperController.cs:119:if (readiness.State != StoreLaunchReadinessState.Ready).MyBox.ShowDialogalways shows: "Store settings are not available yet. Please try again after startup completes." (title "Store Settings Unavailable").ReadyStoreLaunchReadinessStatevalue, 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.StoresWrapperpopulated but permanently unable to resolve, vs. still loading).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
UtilitiesCS/OutlookObjects/Store/StoreWrapperController.cs:119-127. Explicitly flagged as a known, deliberately-deferred follow-up indocs/features/active/2026-07-07-folder-settings-store-model-null-262/spec.md:60-62: "Changing theStoreWrapperController'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 viagh issue list).Impact / Severity
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