How Can I Debug Statamic’s AppServiceProvider Halting Laravel’s Bootstrapping Process?

Below is one explanation that fits what you’re seeing in Laravel 11 with Statamic 5:

---

Likely Cause: Boot Order and Early Resolution

In Laravel 11 the bootstrapping process and the timing of when service providers run has shifted slightly. In your case the Statamic service provider is calling:

PHPCopied
$this->app->make(Schedule::class)->job(new HandleEntrySchedule)->everyMinute();

This call happens during early bootstrapping – before the kernel is fully registered. Meanwhile, your package (ylsideas/feature-flags) registers a macro (skipWithoutFeature on the Event facade) that the scheduling code ultimately ends up needing later in the lifecycle. When the call to schedule a job is made before the macro is available, it does not hit any catchable exception or log because it is essentially operating in a phase where things aren’t “ready” (or the dependency isn’t resolved yet).

This issue is compounded by the fact that an early resolution (making the Schedule instance too soon) may be causing part of the boot process to “freeze” silently. The vendor’s use of early scheduling may be triggering a fatal PHP error—or a misbehaving call sequence—that does not produce a normal exception when using try/catch.

---

How to Debug This Situation

Since nothing is logging or throwing a catchable exception, consider the following debugging steps:

1. Add Logging or Debug Breaks in the Service Provider
   Temporarily modify the problematic service provider (or override it in your own service provider if possible) to log messages on entry and exit. For example:

   PHPCopied
   // In Statamic’s AppServiceProvider (or your override)
   Log::debug('Before scheduling HandleEntrySchedule');
   $schedule = $this->app->make(Schedule::class);
   Log::debug('After instantiating Schedule');
   $schedule->job(new HandleEntrySchedule)->everyMinute();
   Log::debug('After scheduling job');

2. Enable Xdebug or a Similar Debugger
   Use Xdebug to set breakpoints in the vendor code (especially around Application::boot and the Statamic provider method). This will allow you to step through and see exactly where execution halts.

3. Set a Custom Error Handler
   Since the issue might be causing a fatal error that isn’t caught by traditional exception handling, try setting up a custom error or shutdown handler using PHP’s set_error_handler or register_shutdown_function to catch any low-level errors that may be occurring.

4. Review Service Provider Order and Macro Registration Timing
   Check if reordering the booting of the packages or ensuring that the macro is registered earlier makes any difference. It might be necessary to delay the job scheduling until after the kernel (and thus the macro) is fully registered. Often scheduling is better placed within the Console Kernel’s schedule method instead of the service provider boot method.

---

Summary

What you’re likely seeing is a bootstrapping timing issue introduced by Laravel 11’s updated lifecycle. The problematic line in Statamic’s AppServiceProvider calls an early resolution of the Schedule instance before your macro is registered. This can cause a silent failure (or even a fatal error that bypasses typical logging) during the boot process. Debugging this scenario will require inserting logging or breakpoints, enabling a custom error handler, and perhaps revisiting when and where scheduling is performed.

These steps should help pinpoint why execution stops and clarify whether adjusting the boot order or deferring schedule registration is needed.