Failed Image Storage status poll leaves settings controls disabled

assets/src/dashboard/utils/api.js の callSync() から始め、特に loading state の設定と rejected-request handler を確認してから、assets/src/dashboard/parts/connected/settings/OffloadMedia.js がそれらのフラグをどのように使用しているかを追跡します。rejected transfer status request を再現し、Image Storage controls が復旧し、operation error が表示されることを確認します。dashboard の test setup が対応している場合は関連する coverage を追加し、その後 npm test を実行します。

Summary

The Image Storage settings can remain non-interactive after a transfer status request fails. The interface is expected to restore usable controls and display the operation error. Instead, the transfer indicator can disappear while the Image Storage choices and Sync control remain disabled, preventing the user from cancelling or restarting the operation from the screen.

Customer context

• Product / area: Optimole Pro, Image Storage settings UI
• Version: Customer version not provided; inspected source is 4.2.10
• Environment: WordPress; Windows 10 and Firefox reported by ticket metadata
• Integration / third party: No cache reported; the precise failed REST request was not captured
• Reported error / symptom: Image Storage is frozen and controls cannot be clicked
• Impact: The user cannot access normal transfer controls or logs from the affected screen

Reproduction notes

Reported workflow:

1. Return to Optimole > Settings > Image Storage while the transfer remains active.
2. Attempt to use the Image Storage controls.
3. Observe that the screen is non-interactive and Cancel, restart, or log actions cannot be used.

A deterministic source-level trigger is to reject the transfer status request after callSync() sets global loading. No browser runtime reproduction was performed, and the original screenshot is unavailable.

Diagnosis

Conclusion

callSync() sets the dashboard-wide loading state before each transfer status request. Its rejected-request handler clears only transfer-specific loading flags, leaving the global loading state enabled. The Image Storage component then hides the progress controls because transfer loading is false while disabling the normal choices and Sync control because global loading remains true. This is a definite UI state defect for the rejected-poll path and closely matches the reported non-interactive screen.

Where this likely occurs

• assets/src/dashboard/utils/api.js — callSync() lines 479–590: sets isLoading at line 498; the rejection handler at lines 585–589 clears loadingSync and loadingRollback without clearing isLoading.
• assets/src/dashboard/parts/connected/settings/OffloadMedia.js — OffloadMedia lines 312–322 and 370–436: transfer controls depend on transfer-specific flags, while the radio choices and Sync button independently become non-interactive when global isLoading remains true.
• assets/src/dashboard/parts/connected/settings/OffloadMedia.js — mount effect lines 100–114: resumes polling when persisted offload or rollback status is active.
• Git history: blame attributes the current loading/polling behavior to the 2023 transfer UI work, including commits 46e18ee9, 23b50eba, and b070f477; it remains present in inspected version 4.2.10.

Engineering notes

A request rejection, JSON parsing rejection, or unexpected response object can reach the stale-loading path. A handled non-2xx response clears global loading before the following promise rejects, so that narrower branch does not retain the stale flag. The source confirms disabled controls rather than a blocked browser event loop. The original screenshot was unavailable, and no browser console or network response was supplied, so the customer's exact request failure is inferred from the symptom.

Test coverage status

No relevant JavaScript unit or e2e coverage for callSync(), OffloadMedia, rejected status polling, or loading-state recovery was found during inspection. tests/test-media.php covers direct PHP rollback/offload behavior but does not exercise the dashboard state path.

What to verify or explore next

• May be worth reproducing an active rollback followed by a rejected number_of_images_and_pages request and checking the Image Storage controls.
• May be worth checking malformed JSON, nonce rejection, network interruption, and component remount cases separately.
• If reproducible, browser network and console output can identify which rejection branch matches the ticket.
• The dashboard JavaScript test command npm test and relevant e2e dashboard coverage are appropriate verification surfaces if such coverage exists outside the inspected search results.

Unknowns / follow-up

The failing request response, browser console output, customer plugin version, and whether navigation outside Image Storage was also disabled are unavailable. The sanctioned ticket images contained only email signature graphics, not the reported UI screenshot.

Confidence

Confidence: 94/100

Two independently verifiable defects in the Optimole WordPress plugin match the reported stalled rollback and disabled Image Storage UI. The screenshot and site-specific logs are unavailable, so confidence is based on direct source-path evidence rather than a customer-site reproduction.

Source: HelpScout #3411333716
Generated by bug-report-triage (ID: bug-report-triage_6a7f1f81ead033.88694331)