WooCommerce 11.0.1 includes a fix that avoids scanning an entire log directory during cleanup. Stores with years of files, many channels, slow network storage, inode pressure, or concurrent writers need to prove that cleanup remains bounded. A job that deletes the right files can still harm checkout if discovery consumes excessive I/O, memory, or lock time.
Use this for high-volume stores, managed hosts, container platforms, network filesystems, observability teams, and sites with large wc-logs directories.
Quick answer
Inventory file count and age without triggering an unbounded production scan, then clone a representative directory on staging. Run cleanup with a defined batch size, maximum scanned entries, duration, I/O, memory, lock, and customer-latency budget. Confirm retention, active-file protection, cursor progress, safe retry, and concurrent-write behavior before observing one controlled production run.
What to check first
- Record filesystem type, directory path, file count estimate, age distribution, retention policy, writer count, and cleanup schedule.
- Create eligible, protected, active, malformed, future-dated, rotated, compressed, unreadable, and symlink fixtures.
- Measure scanned entries, eligible entries, deleted files, duration, read and write I/O, memory, CPU, lock time, and next cursor.
- Run concurrent logging, interrupted cleanup, repeated cleanup, and two-runner collision tests.
- Watch checkout, Store API, cron, worker, disk, inode, and error-rate baselines during the controlled run.
Why this usually happens
- Directory enumeration can become the dominant cost before deletion begins.
- Network filesystems amplify metadata reads and lock delays.
- Timestamp or naming assumptions can misclassify active and malformed files.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
run,total_estimate,scanned,eligible,deleted,duration_s,read_mb,memory_mb,next_cursor,checkout_p95_ms
C-811,20000,500,126,125,8.4,19,74,000500,612
C-812,20000,500,141,141,8.1,18,72,001000,598
C-813,20000,500,0,0,1.2,3,44,001500,590
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Define retention, active-file protection, and operational budgets. | Record filesystem type, directory path, file count estimate, age distribution, retention policy, writer count, and cleanup schedule. | Active, protected, and out-of-policy files remain untouched. |
| Build a production-like directory fixture on staging. | Create eligible, protected, active, malformed, future-dated, rotated, compressed, unreadable, and symlink fixtures. | Scanned and deleted counts stay inside the configured batch. |
| Use bounded enumeration, deletion batches, cursors, and a single-runner lock. | Measure scanned entries, eligible entries, deleted files, duration, read and write I/O, memory, CPU, lock time, and next cursor. | Interrupted and repeated runs resume without duplicate harm. |
| Make interruption and retry idempotent. | Run concurrent logging, interrupted cleanup, repeated cleanup, and two-runner collision tests. | Checkout latency, Store API errors, disk, and queue health remain in budget. |
Decision rule
Approve cleanup when each run stays within scan, duration, I/O, memory, lock, and customer-latency budgets while deleting only eligible files and making durable cursor progress.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Small batch | 100 eligible of 20,000 | Bounded scan and cursor |
| Active log | Writer holds current file | Never deleted |
| Interrupted job | Stop after first batch | Retry resumes safely |
| Concurrent runners | Two cleanup starts | Lock prevents duplicate work |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Define retention, active-file protection, and operational budgets.
- Build a production-like directory fixture on staging.
- Use bounded enumeration, deletion batches, cursors, and a single-runner lock.
- Make interruption and retry idempotent.
- Observe one production run with checkout and worker guardrails.
Production verification checklist
- Active, protected, and out-of-policy files remain untouched.
- Scanned and deleted counts stay inside the configured batch.
- Interrupted and repeated runs resume without duplicate harm.
- Checkout latency, Store API errors, disk, and queue health remain in budget.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not treat a successful request, quiet log, or correct screenshot as proof that the complete user outcome is correct.
- Do not leave debug logs, test records, broad credentials, temporary roles, or browser overrides active after verification.
- Do not close the work without recording versions, fixture IDs, UTC timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, roles, data volume, cache, browser behavior, and integrations. Finish with one controlled production fixture when the result depends on the real CDN, email provider, worker clock, crawler response, or browser storage.
What evidence should be retained?
Keep exact versions, stable IDs, UTC timestamps, sanitized requests or logs, expected result, actual result, decision, and final verification. Redact customer data, cookies, secrets, order keys, and full advertising identifiers.
When should the change be rolled back?
Roll back when a revenue, privacy, accessibility, security, publishing, or lead path fails and the cause cannot be isolated inside the approved maintenance window. Preserve the failed fixture before rollback.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, diagnose WooCommerce log cleanup.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references