Bug Catcher Laravel Package

Getting Started

Start by confirming you are on v2.0.0-RC3 and that the project delete action is visible again in the admin project list. If your application had hidden or removed that action because it previously failed on foreign-key constraints, this release is the point to restore it.

The first practical use case is the admin workflow: delete a project and verify that its related record, perf_bucket, and record_log_withholder rows are removed as part of the same operation, with the project row deleted last. Check this in a staging environment before relying on it in production.

For Laravel integration, clear config/route caches after upgrading, confirm the admin route and authorization policy for project deletion are still wired correctly, and make sure any Doctrine EntityManager setup used by the package is configured as before.

Implementation Patterns

Treat project deletion as an orchestrated application operation, not as a single $em->remove($project) call. The package now deletes dependents explicitly and deletes the project last, which avoids relying on inconsistent database-level cascades.

No extra work is required for record types, including custom ones: records are removed through BatchRecordDeleteInterface, so a custom record type is covered with nothing more to write. If you already have a custom implementation of that interface on a record type or deletion handler, it will continue to be used — just confirm it is still registered the same way other package extensions are.

In admin controllers or Livewire/Filament actions, call the package’s project deletion action/service rather than reproducing the old entity-manager-only logic. Keep authorization checks around the action, because restored UI actions can expose deletion to users who previously could not see it.

Add an integration test that creates a project with records, performance buckets, and withholders, deletes it through the admin path, and asserts that all dependent rows are gone and no foreign-key violation occurs. Add a second test that exercises a custom record type to confirm it is deleted through the batch path without any extra wiring.

Gotchas and Tips

Do not reintroduce a direct $em->remove($project)-only deletion path. The original failure came from mixed foreign-key behaviour: record and perf_bucket cascade, but record_log_withholder does not, so the database can refuse the single DELETE FROM project.

If a custom record type still leaves rows behind or causes a constraint error, the problem is almost certainly not in your deletion code — check that the record type is actually resolvable by the package (correct registration/discovery, container bindings, or configuration) so it reaches BatchRecordDeleteInterface at all.

Because this is an RC release, pin the version in composer.json, test the admin deletion workflow on staging, and watch for any follow-up changes to the deletion API. When debugging failures, enable SQL logging and inspect the delete order: dependents should be removed first, project last. Also verify that the admin action is not still hidden by local configuration, permissions, or cached views after upgrade.