Laravel debugging after updates

• Deep Dive into PHP-FPM's php.ini Configuration:

  This is often the culprit for early request errors. You mentioned checking php-fpm logs, which is a great start, but we need to ensure PHP itself is configured to log *everything* internally. There are often multiple php.ini files (one for CLI, one for FPM). Make sure you're editing the one used by your web server's PHP-FPM process (you can typically find its path using phpinfo() or php -i | grep 'Loaded Configuration File' when run as the FPM user).

  • display_errors = Off: Absolutely essential for production. If this is `On`, PHP might just output the error to the browser/response body and not log it fully.
  • log_errors = On: This *must* be `On`. It tells PHP to log errors to the specified `error_log` directive.
  • error_reporting = E_ALL: Set this to `E_ALL` to ensure PHP reports every possible error, warning, and notice. Laravel handles the display of these, but PHP needs to internally register them first.
  • error_log = /var/log/php-fpm/error.log: Define a specific path for PHP's native error log. This log is separate from Laravel's `storage/logs/laravel.log` and will catch errors *before* Laravel's handler. Ensure the PHP-FPM user has write permissions to this directory. This is your primary fallback for anything Laravel misses.
• Nginx Web Server Configuration:

  While Nginx usually passes control to PHP-FPM, it can sometimes intercept errors. Verify these settings in your Nginx site configuration:

  • fastcgi_intercept_errors off;: This is crucial. If `on`, Nginx might try to handle 500 errors itself (e.g., serving a static 500.html) instead of letting PHP-FPM and Laravel process them. Set it to `off` to ensure PHP-FPM gets the full error context.
  • Check your Nginx `error_log` path. This will show you if Nginx itself is having trouble connecting to PHP-FPM or if PHP-FPM is crashing entirely.
• Early Laravel Bootstrapping & Custom Handlers:

  For exceptions happening *very* early, even before the Laravel Application instance is fully constructed, you need to go lower level. Laravel's `public/index.php` is the first entry point. You could, as a last resort for debugging, temporarily inject a custom error handler right at the top of this file:

  <?php
  
  // Temporarily for deep debugging
  set_error_handler(function ($severity, $message, $file, $line) {
      // Log using PHP's native error_log, or even write to a temporary file
      error_log(sprintf("[%s] %s in %s on line %d", date('Y-m-d H:i:s'), $message, $file, $line));
      // You can also re-throw to let Laravel handle it if it can
      // if (!(error_reporting() & $severity)) {
      //     return;
      // }
      // throw new ErrorException($message, 0, $severity, $file, $line);
  });
  
  set_exception_handler(function ($exception) {
      // Log using PHP's native error_log
      error_log(sprintf("[%s] Uncaught exception: %s in %s on line %d", date('Y-m-d H:i:s'), $exception->getMessage(), $exception->getFile(), $exception->getLine()));
      // Optionally, dump to stderr for FPM logs
      fwrite(STDERR, "Uncaught Exception: " . $exception->getMessage() . "\n" . $exception->getTraceAsString() . "\n");
  });
  
  // Continue with Laravel's normal bootstrap
  require __DIR__.'/../vendor/autoload.php';
  // ... rest of public/index.php

  This will catch *any* PHP error or uncaught exception that occurs before Laravel's `Application` instance is fully bootstrapped and its own `ExceptionHandler` is registered. Remember to remove this once you've identified the issue, as it bypasses Laravel's robust handling.

• Queue Workers and CLI Context:

  Queue workers run as separate CLI processes. They use the CLI's `php.ini` (which can be different from your FPM's `php.ini`) and have their own lifecycle. Ensure your CLI `php.ini` has the `log_errors = On` and `error_log` directives correctly configured. Also:

  • Environment Variables: Double-check that `APP_ENV` and `APP_DEBUG` are correctly set for your worker processes. If your workers are running in `production` with `APP_DEBUG=false`, Laravel will be less verbose.
  • Supervisor/Systemd Logs: If you're using Supervisor or Systemd to manage your workers, check their `stdout` and `stderr` logs. Uncaught exceptions in queue jobs often get dumped there.
  • Explicit Logging in Jobs: For critical job logic, wrap it in a `try-catch` block and explicitly log errors using `Log::error()` or `report($e)` within the catch block. This ensures that even if something goes wrong, you're explicitly telling Laravel to log it.
• Verify Logging Configuration (Beyond the Basics):

  You mentioned checking `logging.php`, which is good. Ensure your 'stack' channel is indeed configured to push to 'daily' and that the 'daily' log files (`storage/logs/laravel-YYYY-MM-DD.log`) are actually being written to and rotated correctly. File permissions are a common overlooked issue here; the web server user (e.g., `www-data` or `nginx`) needs write access to `storage/logs/`.

So, really appreciate you laying all this out Yumi, gives me a lot to check...