Offload-limit warning remains after account usage drops #1118

Status (2026-10-11)

Fixed in PR #1176 (bugfix/1118 → development, approved by pirate-bot at a34edda3).

• Fix: the daily sync now compares the account usage with the offload limit. Below the limit it clears the "offload limit reached" warning, and it stores the account's real limit, so the warning no longer shows the 50,000 default.
• Also fixed: the upload check counted the images of an earlier bulk transfer that had already ended (or of a rollback), so one upload could set the warning on an account far below its limit. Only an offload that is still running counts now, from the dashboard or from WP-CLI.
• Tests: the daily sync with usage below the limit, at the limit, and without usage details; nine cases for the upload check (rollback, dashboard and WP-CLI offloads that are running, ended or interrupted). They fail on development.
• To know: an account that really is at its limit gets the warning back on its next upload.
• Not proven: against the live account API (mocked in the tests), and the WP-CLI offload on a connected site.

Summary

The WordPress Optimole settings can continue showing the offload-limit warning after account usage has fallen below the plan limit. Expected behavior is for refreshed account usage to clear an obsolete warning. Actual behavior is a persisted warning that displays the stored 50,000-image limit despite substantially lower dashboard usage, which can incorrectly indicate that further offloading is unavailable.

Customer context

Product / area: Optimole WordPress plugin, Image Storage offloading status
Version: Customer version not provided; inspected source is 4.2.11
Environment: WordPress admin; browser and WordPress/PHP versions not provided
Integration / third party: Optimole account service and dashboard
Reported error / symptom: Plugin shows a 50,000-images-offloaded warning while the account dashboard shows 1,181 assets
Impact: Administrators receive an inaccurate quota warning after deleting environments

Reproduction notes

Reported reproduction:

1. Delete duplicate Optimole environments so account usage drops.
2. Confirm the Optimole dashboard shows 1,181 assets.
3. Open the Optimole WordPress plugin settings.
4. Observe the 50,000-images-offloaded limit warning.

The customer report was not reproduced in a local runtime, but the stale-state path is directly present in the inspected source.

Diagnosis

Conclusion

The warning state is persisted independently from refreshed account usage. Optml_Admin::daily_sync() refreshes service_data but does not reconcile offload_limit_reached, while the settings UI renders the warning solely from that persisted flag and a locally stored limit. A previous support investigation also classified false offload-limit warnings as a UI notification defect. No matching GitHub issue was found.

Where this likely occurs

• inc/admin.php — Optml_Admin::daily_sync() lines 1130–1158 refreshes account service data without updating the persisted offload-limit warning state.
• inc/admin.php — Optml_Admin::localize_dashboard_app() lines 1409–1477 passes account data and the local offload_limit to the dashboard as separate values.
• inc/settings.php — Optml_Settings::$defaults lines 102–103 defines the persisted warning flag and the 50,000 fallback limit.
• assets/src/dashboard/parts/connected/settings/OffloadMedia.js — OffloadMedia lines 438–440 renders the warning whenever offloadLimitReached is true, without comparing refreshed usage.
• assets/src/dashboard/utils/api.js — callSync() lines 525–546 updates the warning state only in a terminal transfer-response branch.
• inc/media_offload.php — Optml_Media_Offload::generate_image_meta() lines 1384–1400 persists the reached state during the proactive quota check; lines 1446–1457 persists it after an upload-limit exception.
• Commit 7b8a68f8 introduced offloading-limit notifications. Available history does not establish an earlier working release followed by a regression.

Engineering notes

The displayed 50,000 value can come from the plugin's local default or a previously stored service limit; it is not the current asset count. The dashboard's 1,181 assets and the SDK's offload-usage value may represent different service fields, so the account-specific discrepancy remains dependent on service data. The confirmed defect is the lack of reconciliation for an already persisted warning when account information refreshes.

Test coverage status

No relevant coverage was found during inspection for stale offload_limit_reached state, daily-sync reconciliation, or warning rendering. tests/test-media.php exercises offload processing and mocked account details but does not assert warning state transitions.

What to verify or explore next

• May be worth reproducing after reducing usage below the limit, running the account refresh, and reopening Optimole settings.
• May be worth capturing the SDK getUsage() current and limit values alongside refreshed service_data in a controlled test account.
• If reproducible, checking both a completed bulk transfer and a newly uploaded attachment would clarify which warning-state path persists.

Unknowns / follow-up

• The customer's plugin version and locally persisted Optimole settings are unavailable.
• The service-side usage payload and whether environment deletion immediately changes SDK offload usage are unavailable.

Confidence

Confidence: 92/100

Repository inspection independently confirms a stale offload-limit warning path and a missing local download target after offload. The blank-rendering symptom is credible but remains unconfirmed without the affected remote response or offloading logs.

Source: HelpScout #3431088020
Generated by bug-report-triage (ID: bug-report-triage_6a8f62001e0958.60696283)