Problem
The current system decides whether to kill a query based on how long it ran and where it ran (admin, frontend, cron, etc.). But not all slow queries carry the same risk if killed. A 10-second background analytics rollup and a 10-second checkout coupon validation are very different situations — one is invisible, the other breaks a purchase.
Without this distinction, we're forced to choose between aggressive enforcement (risk killing harmless background work or disrupting checkout) and conservative enforcement (letting genuinely dangerous queries run too long).
Concept
Add a second dimension to query enforcement: consequence severity. Instead of just "how slow?" and "what context?", also consider "what happens if this query gets killed?"
| Consequence tier |
Examples |
Suggested behavior |
| Invisible |
Report caches, analytics rollups, subscription stats |
Kill freely — nobody notices, retries are cheap |
| Retry-safe |
Inventory sync, background imports, fraud-status checks |
Kill is fine — Action Scheduler retries automatically |
| User-visible |
Admin search, product page queries |
Kill with caution — user sees an error, but no data loss |
| Transactional |
Checkout validation, coupon checks, payment gateway queries |
Avoid killing — disrupting this can lose a sale |
Use case
Bloomzhemp's first 3.5 days of v2 observation captured one slow query: a WooCommerce Subscriptions report cache update (5.3 seconds, Action Scheduler context). This query is completely harmless — if killed, it just retries later and nobody notices. But under the current model, it would be treated the same as a 5-second query blocking a checkout page.
Consequence-aware thresholds would let us enforce aggressively on low-risk background queries (keeping the database healthy) while giving more headroom to high-stakes transactional queries (protecting revenue).
Relationship to current work
This builds on top of the v2 db.php drop-in (#31), which enables 100% observation at near-zero overhead. The observation data collected in v2 is what makes informed consequence classification possible — you need to see what's actually slow before you can decide what to do about it.
Problem
The current system decides whether to kill a query based on how long it ran and where it ran (admin, frontend, cron, etc.). But not all slow queries carry the same risk if killed. A 10-second background analytics rollup and a 10-second checkout coupon validation are very different situations — one is invisible, the other breaks a purchase.
Without this distinction, we're forced to choose between aggressive enforcement (risk killing harmless background work or disrupting checkout) and conservative enforcement (letting genuinely dangerous queries run too long).
Concept
Add a second dimension to query enforcement: consequence severity. Instead of just "how slow?" and "what context?", also consider "what happens if this query gets killed?"
Use case
Bloomzhemp's first 3.5 days of v2 observation captured one slow query: a WooCommerce Subscriptions report cache update (5.3 seconds, Action Scheduler context). This query is completely harmless — if killed, it just retries later and nobody notices. But under the current model, it would be treated the same as a 5-second query blocking a checkout page.
Consequence-aware thresholds would let us enforce aggressively on low-risk background queries (keeping the database healthy) while giving more headroom to high-stakes transactional queries (protecting revenue).
Relationship to current work
This builds on top of the v2 db.php drop-in (#31), which enables 100% observation at near-zero overhead. The observation data collected in v2 is what makes informed consequence classification possible — you need to see what's actually slow before you can decide what to do about it.