[somethingwithproof]

This change keeps Boost samples available for retry when a database copy, RRD write or acknowledgement fails. It stops after a rejected buffer and deletes only the keys fetched and successfully stored, using staged keys for the acknowledgement. This prevents later writes or late-arriving samples from being lost through an overly broad cleanup.

Implementation details

When an on-demand Boost buffer fails, processing continues to later timestamps. Those writes can advance the RRD past retained samples, preventing a safe retry. Stop at the first rejected buffer and preserve the queue. Also distinguish a failed source-existence query from a confirmed deleted source so a database failure cannot acknowledge unstored samples.

Temporary-table creation and archive/active-queue copies must all succeed before processing or archive cleanup. A failed copy can otherwise leave the temporary table incomplete and delete closed-round samples that never reached an RRD. Retain those archives, remove any temporary table created by the failed attempt, and release legacy locks before returning failure.

Acknowledge only fetched keys, rather than deleting every row before the cutoff. This preserves late arrivals that were not included in the successful RRD update. The fetched keys are staged in a temporary table and removed by one primary-key delete, so a failed delete leaves every fetched row staged for the next run.

Eight isolated regression cases execute the production functions and cover buffer failures, deleted sources, metadata reads, archive-copy and temporary-table failures, and the all-or-nothing key acknowledgement. The develop Boost suite passes 95 tests on PHP 8.5.11 through mise. Formatting, full PHPStan analysis, and SQL/security guards pass. The matching maintenance suite runs 24 real MariaDB/RRDtool integration cases, including late arrivals and safe retries.

Follow-up to #8332. The maintenance fixes and database/RRDtool handoff cases are in #8334.

Acknowledging with a (rrd_name, time) IN (...) list was slow on large backlogs: the list does not follow the primary key's column order and degrades roughly quadratically. The delete now joins against the staged keys. Timings for one data source's backlog, in seconds, from the real boost_delete_output_keys in Docker against a table holding 100,000 rows of other data sources (the old range delete is shown for reference; it also deletes late arrivals):

Rows	MariaDB 10.11 old range	MariaDB 10.11 previous revision	MariaDB 10.11 now	MySQL 8.0 old range	MySQL 8.0 previous revision	MySQL 8.0 now
600	0.003	0.098	0.004	0.005	0.008	0.007
5,000	0.011	1.266	0.027	0.021	0.059	0.040
50,000	0.103	12.893	0.221	0.176	0.590	0.332

Late-arriving rows and other data sources survive in every run. A per-timestamp point delete was slower still (4.7 s at 5,000 rows on MariaDB) and a (time, rrd_name) reorder of the IN list did not help.

Revision and checks

Description scope: target develop, 9 changed files, head 55cd0c333. Checked 2026-10-23 03:06:04 UTC.

GitHub check snapshot: 2 passed. Local test figures and earlier CI runs above are recorded evidence for their stated revisions and environments; they do not assert that every check passes at this head.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud