Bug Catcher Laravel Package

Technical Evaluation

Architecture fit The package owns a project → record → perf_bucket → record_log_withholder object graph and has now moved referential-integrity responsibility out of the database schema and into application code. Previously the delete was a single DELETE FROM project trusting FK cascade rules; because record_log_withholder has no cascade while record and perf_bucket do, the statement was refused outright. The fix deletes dependents explicitly and the project last. Architecturally this is a reasonable, portable choice (it no longer depends on every environment's FK configuration agreeing), but it converts a schema-enforced invariant into a code-enforced one that must be maintained by hand as the model grows.

Integration feasibility Straightforward for consumers using stock record types — the delete path is self-contained. The relevant seam is BatchRecordDeleteInterface: custom record types are covered provided they implement it. That is the one integration task we own. Feasibility drops to "unknown" until we confirm whether that interface is a stable public contract or an internal detail that leaked into the release note.

Technical risk

• This is RC3 of a 2.0.0 major, not GA. The API is not frozen and 2.0.0 implies breaking changes versus 1.x that these notes do not enumerate.
• Deletion semantics changed materially: an operation that previously always failed now permanently removes records, buckets and withholders. That is a destructive capability being re-enabled, and the notes say nothing about a confirmation step, soft delete, authorization check, transaction boundary, or audit/event dispatch.
• The release note describes the symptom fix (delete works) but not the safety fix (partial failure handling). If the sequence is not wrapped in a transaction, a mid-sequence failure leaves the project intact with some dependents already gone.
• Mixed provenance signal: the code shown ($em->remove(), entity manager, cascade semantics) reads as Doctrine/Symfony, not Eloquent. If we are consuming this as a Laravel package, we need to know what that abstraction actually is before we plan around it.

Key questions

1. Is BatchRecordDeleteInterface a supported public extension point, and what is its stability commitment across 2.0.x?
2. Is the dependent-deletion sequence executed inside a single transaction? What is the documented behavior on partial failure?
3. What is the GA date for 2.0.0, and what is the full breaking-change list versus 1.x?
4. Does deletion fire domain events, write an audit log, or support soft delete/restore? If not, is that planned?
5. Is there an authorization and confirmation gate on the admin action, or does re-exposing the button make deletion a one-click operation?
6. Which ORM/persistence abstraction is this actually built on, and does it assume MySQL/Postgres FK semantics anywhere else?

Integration Approach

Stack fit The package slots into the admin/application layer cleanly; the change is internal to a delete handler and does not introduce new infrastructure. The open stack question is the persistence layer: the entity-manager style in the notes suggests a Doctrine-style unit of work, which behaves differently from Eloquent around cascade and flush ordering. Confirm before we commit to an integration design.

Migration path Treat 2.0.0-RC3 as pre-release only: staging and feature-flagged environments, no production deploy. The practical migration work is (a) audit every custom record type we own against BatchRecordDeleteInterface, and (b) verify that anything relying on the old behavior — including any workaround where we hid or disabled the delete action ourselves — is removed. Do not plan a 1.x → 2.0 cutover until GA and the breaking-change list land.

Compatibility

• Custom record types that do not implement the interface will reproduce the original FK error and block project deletion. That failure is at least loud and safe, but it is a per-tenant surprise.
• Any dependent table added to the schema after this release must be manually registered in the delete sequence; there is no schema-driven fallback left.
• Environments with differing FK configurations (dev vs prod, MySQL vs Postgres) will now behave consistently — a genuine win over the previous state.

Sequencing

1. Confirm interface stability and transaction semantics with the maintainer (blocking).
2. Inventory and implement BatchRecordDeleteInterface on all in-house record types.
3. Test deletion against a production-shaped dataset, including a custom record type that does not implement the interface, to confirm failure is clean rather than partial.
4. Add confirmation/authorization on the admin action before enabling it for users.
5. Gate production adoption on 2.0.0 GA.

Operational Impact

Maintenance A permanent standing tax: every future dependent table must be added to the explicit delete sequence. This is exactly the kind of omission that produces the same class of bug in six months, and it will not be caught by the database. Add a checklist item to the schema-change process.

Support Support load shifts character rather than volume. "Delete project is broken" tickets stop; "I deleted the wrong project, restore it" tickets begin. With no documented restore path, those become engineering escalations. Brief the support team and prepare a runbook before the action is visible in the UI.

Scaling The delete is now a multi-statement, order-dependent operation whose cost scales with the size of the project's record history. Large projects risk request timeouts, long-held locks and replica lag. The BatchRecordDeleteInterface naming implies chunked deletion, but the notes do not confirm batching, chunk size, or whether the whole thing runs synchronously in the admin request. For our larger tenants this is the main operational unknown.

Failure modes

• Non-transactional partial delete — the worst case: project survives, some dependents are gone. Silent, hard to detect, hard to reconcile.
• Missing interface implementation — delete fails with the original FK error; recoverable, but a confusing support experience.
• Unbounded synchronous delete — timeout mid-flight, compounding the partial-delete risk.
• Destructive action with no audit trail — records and withholders disappear with no documented event or log entry, which is a compliance exposure if any of that data is in scope.
• RC churn — a behavior change between RC3 and GA invalidating staging results.

Ramp-up Low for admin users — the action simply returns. Moderate for our developers, who must understand the interface and the manual cascade list. One half-day of engineering plus a runbook and a support briefing is a realistic estimate, with the caveat that the interface-stability and transaction answers could change that materially.