Skip to content

fix: clear a stale offload limit warning once the account is below the limit - #1176

Open
selul wants to merge 1 commit into
developmentfrom
bugfix/1118
Open

selul wants to merge 1 commit into
developmentfrom
bugfix/1118

Conversation

@selul

@selul selul commented Oct 9, 2026

Copy link
Copy Markdown
Contributor

Related issue: #1118

The "offload limit reached" warning stayed after the account usage dropped, with the 50,000 default as the limit. The flag behind it was only cleared when a bulk offload started, and while it was set new uploads silently stopped being offloaded. The daily sync now reconciles it with the account usage.

What changed

  • Optml_Admin::daily_sync() — the account details already include offload_limit and offloaded_images. The sync stores the limit, and clears the flag when the account is below it.
  • Upload limit check (Optml_Media_Offload::generate_image_meta())
    • stores the account's limit with the flag, as the upload-exception path already did, so the warning shows the real limit, not the 50,000 default;
    • counts the images still to upload (optml_process_meta "remaining") only while a bulk offload runs. move_images() records "remaining" for rollbacks too, and it stays after a run, so after a large rollback a single upload could set the flag although the account was far below the limit.

Note

If the account really is at its limit, the next upload sets the flag again (preflight or upload exception), so clearing it daily cannot hide a real limit for long.

Tests

  • tests/test-offload-limit-sync.php (new): the daily sync clears the warning and stores the limit when usage is below it, keeps it at the limit, and changes nothing without usage details.
  • tests/test-media.php: stale rollback progress does not trip the limit (the upload is offloaded); during a bulk offload the check still trips and stores the account limit.
  • All four fail on development. Mutations (<= instead of <, limit not stored by the sync or the check, stale "remaining" counted) each fail a test.

QA

  1. On a connected site, trigger the warning (or set the offload_limit_reached setting to enabled with WP-CLI: wp eval '( new Optml_Settings() )->update( "offload_limit_reached", "enabled" );').

  2. Run the daily sync: wp cron event run optml_daily_sync.

    Expect: in WP Admin → Optimole → Settings → Image Storage, the limit warning is gone, and a new upload is offloaded.

Verification (head a9fcc18f)

Check Result
PHPUnit, full suite, PHP 8.4 (WP 7.1.3) PASS: 369 tests (baseline 364 + 5 new)
tests/test-media.php and tests/test-offload-limit-sync.php, each run alone PASS: 25 and 3 tests
phpcs, phpstan (build-only include errors excluded locally; CI builds assets first) PASS

Not proven

  • Against the live account API (mocked in the tests with the fields the service sends).

🤖 Generated with Claude Code

…e limit

The "offload limit reached" flag was set by the upload check and cleared
only when a bulk offload started, so the warning stayed after the account
usage dropped (for example after duplicate sites were removed). It also
silently stopped new uploads from offloading.

- The daily sync stores the account's offload limit and clears the flag
  when the account is below it again.
- The upload check stores the account limit with the flag, so the warning
  no longer shows the 50,000 default.
- The upload check counts the images still to upload only while a bulk
  offload runs. The progress of a finished offload or of a rollback (which
  records how many images it moves back) no longer counts toward the limit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@pirate-bot

Copy link
Copy Markdown
Collaborator

Plugin build for a9fcc18 is ready 🛎️!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants