Bruno Martinez

Hi,

I’m reporting an issue we observed on a high-traffic WordPress site using 404 Solution.

The site started showing repeated 507 Insufficient Storage errors in wp-admin and during normal WordPress operations. After investigation, the server did not appear to be out of disk space or inodes:

– Disk: ~614 GB total / ~141 GB free
– Disk usage: ~77%
– Inodes: ~19% used
– PHP: 8.3 / LiteSpeed / CloudLinux-style shared hosting environment

The 507 errors appeared to be caused by server resource pressure, not actual storage exhaustion.

Evidence found

The WordPress error_log repeatedly showed 404 Solution / abj404 rebuild errors, including:

text<br>WordPress database error Illegal mix of collations<br>(utf8mb4_general_ci,IMPLICIT) and (utf8mb4_unicode_520_ci,IMPLICIT)<br>for operation '='<br><br>query:<br>SET STATEMENT max_statement_time=60 FOR<br>/* abj404:src=DataAccessTrait_LogsHitsRebuild::hitsTableInsertChunked#phase2Aggregate */<br>INSERT INTO smt_abj404_logs_hits_temp<br>(requested_url, logsid, last_used, logshits, failed_hits)<br>SELECT a.requested_url, MIN(a.logsid), MAX(a.last_used), SUM(a.logshits), SUM(a.failed_hits)<br>FROM smt_abj404_logs_hits_preagg a<br>INNER JOIN smt_abj404_redirects r<br>ON a.requested_url = COALESCE(r.canonical_url, CONCAT('/', TRIM(BOTH '/' FROM r.url)))<br>GROUP BY a.requested_url<br>

And also:

text<br>WordPress database error Query execution was interrupted (max_statement_time exceeded)<br><br>query:<br>SET STATEMENT max_statement_time=10 FOR<br>/* abj404:src=DataAccessTrait_LogsHitsRebuild::hitsTableInsertChunked#phase1Chunk */<br>INSERT INTO smt_abj404_logs_hits_preagg<br>(requested_url, logsid, last_used, logshits, failed_hits)<br>SELECT canonical_url, MIN(id), MAX(timestamp), COUNT(*),<br>SUM(CASE WHEN dest_url = '' OR dest_url IS NULL THEN 1 ELSE 0 END)<br>FROM smt_abj404_logsv2<br>WHERE id >= 4961718 AND id < 5061718<br>GROUP BY canonical_url<br>

We also found that the plugin had large internal tables:

text<br>smt_abj404_redirects ~604 MB / ~630k rows<br>smt_abj404_view_done ~516 MB<br>smt_abj404_logsv2 ~181 MB<br>smt_abj404_logs_hits ~7 MB<br>

The scheduled event abj404_rebuildViewDone appeared to be continuously re-created by:

php<br>PluginLogicTrait_Lifecycle::scheduleViewDoneWarmup()<br>

Specifically, the logic appears to schedule it again whenever there is no existing scheduled event:

php<br>if (wp_next_scheduled('abj404_rebuildViewDone') !== false) {<br>return;<br>}<br>wp_schedule_single_event(time() + 5, 'abj404_rebuildViewDone');<br>

In our case, the event was repeatedly scheduled near-immediately, and the rebuild process was hitting database limits / collation issues / long-running queries. This likely created enough resource pressure for the host to return intermittent 507 Insufficient Storage errors.

Temporary mitigation applied

To stabilize the site, we temporarily:

1. Cleared the stuck scheduled event:

php<br>wp_clear_scheduled_hook('abj404_rebuildViewDone');<br>

2. Removed stale/inflight transient state:

text<br>_transient_abj404_inflight_%<br>_transient_timeout_abj404_inflight_%<br>smt_abj404_view_warmup_%<br>

3. Scheduled abj404_rebuildViewDone far in the future instead of allowing it to immediately run again.

After doing this:

– wp-admin and REST requests returned normally again.
– The 507 errors stopped during validation.
– No disk/inode shortage was present.

Suggested fixes

Could you please investigate the following areas?

1. Collation-safe joins
– The rebuild query joins columns with different collations:
– utf8mb4_general_ci
– utf8mb4_unicode_520_ci
– The plugin should either normalize table/column collations during schema upgrades or explicitly apply compatible collation/casts in joins.

2. Safer rebuild scheduling
– abj404_rebuildViewDone should probably not be re-created every request at time() + 5 if the previous rebuild recently failed or exceeded DB limits.
– Please consider adding:
– exponential backoff;
– failure counters; (1/2) > Hermes BRU: – cooldown after max_statement_time failures;
– a lock that survives failed requests;
– admin notice instead of immediate retry loops.

3. Adaptive batch sizing
– The logs-hits rebuild should reduce batch size after max_statement_time exceeded.
– In our logs, a chunk of 100k IDs was too heavy for the environment.

4. Large-site guardrails
– On sites with hundreds of thousands of redirects/log rows, the plugin should avoid expensive admin-triggered rebuilds unless explicitly requested.
– It may need a “manual rebuild only” mode or a safe background queue with throttling.

5. Stale transient cleanup
– Stale _transient_abj404_inflight_% and smt_abj404_view_warmup_% entries seemed to accumulate.
– The plugin should detect and clean abandoned rebuild state automatically.

6. Admin page degradation
– If rebuild data is unavailable, the admin table should degrade gracefully instead of triggering heavy rebuilds that can destabilize the site.

In short: the plugin seems to enter a rebuild/retry loop on large datasets when DB time limits or collation mismatches interrupt the rebuild. This can cause severe resource pressure and intermittent 507 errors, even when disk space is available.

Please let me know if you need additional logs, table schemas, or environment details. (2/2)

• This reply was modified 1 week, 4 days ago by Bruno Martinez.

I don’t think that’s the case. The process still didn’t conclude correctly: https://nimb.ws/Y6fC8zT

Hello Aaron and thank you for the update.

Unfortunately, it still did not work. 🙁

Here are the latest error messages after I’ve updated the plugin: https://www.loom.com/share/66c6d3c7e6234f5ea40de189e3c3bcd8

• This reply was modified 3 weeks, 3 days ago by Bruno Martinez.

Thanks!

Just to let you know, I’ve installed version 4.1.13. Unfortunately, it still fails to load the redirections page. Here’s a video showing it: https://www.loom.com/share/7114b8e5a089426da6cdb5685814e9a4

Error screens:

https://nimb.ws/VpKQbrF

https://nimb.ws/jygxl47

https://nimb.ws/1eBRuIg

Alerts:

Could not finish refreshing data (stage 1, getCapturedURLSPageTable() -> getRedirectsForView() / getRedirectsForView.sql)

404 Solution: AJAX error while updating the table.What was happening: Rendering bottom pagination links Query: getPaginationLinks(bottom) -> getRedirectsForViewCount() / getRedirectsForView.sql HTTP status: textStatus: timeout errorThrown: timeout action: ajaxUpdatePaginationLinks subpage: abj404_logs Elapsed: 45006ms Timeout budget: 45000ms Inflight stage: paginationLinksBottom

Guys, the plugin broke again. It is failing to load the configuration page and breaking redirects: https://nimb.ws/SC1xiFZ

Thanks, pages are now showing, so that’s an advance!

But I still have the redirection errors now. Please take a look: https://www.loom.com/share/cf742d5a8f4b4025be8d8c6dedf4896b

Thank you, but it seems it made no difference. This page is still blank: https://www.showmetech.com.br/wp-admin/options-general.php?page=abj404_solution

Here’s a video showing it: https://www.loom.com/share/c509aee3fa8041e487d79dd23db4b3f0