Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

luanfreitasdev
Copy link
Contributor

Reopen: #56865

The Problem

When a package like spatie/laravel-ignition is installed, it provides its own ExceptionRenderer. However, the framework's default exception listener is still registered alongside it. This causes every exception to be handled twice, resulting in redundant work and unnecessary memory usage (e.g., populating $queries when it is not needed).

Simple Recreation

  1. Install spatie/laravel-ignition in a fresh Laravel project.
    composer require spatie/laravel-ignition
  2. Create a route that throws an exception:
    // routes/web.php
    Route::get('/test-exception', fn() => throw new Exception('test'));
  3. Temporarily add a dd() to the framework's default listener to see it run:
    // In vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Renderer/Listener.php:73
    // Inside the Listener class, method onQueryExecuted()
    public function onQueryExecuted(QueryExecuted $event)
    {
        if (count($this->queries) === 100) {
            return;
        }
    
        $this->queries[] = [
            'connectionName' => $event->connectionName,
            'time' => $event->time,
            'sql' => $event->sql,
            'bindings' => $event->bindings,
        ];
    
        dd($this->queries); 
    }
  4. Access /test-exception in the browser. You will see the dd() message, proving the default listener ran when it shouldn't have.

The Solution

This PR adds a check (! $this->app->bound(ExceptionRenderer::class)) to ensure the default listener is only registered if no other ExceptionRenderer has already been bound to the container. This cleanly prevents the duplication.

Tests

  • Added test to ensure listeners are not registered if ExceptionRenderer exists.
  • Added test to ensure listeners are registered if ExceptionRenderer does not exist.

@luanfreitasdev luanfreitasdev changed the title Prevent unnecessary query logging on exceptions with a custom renderer [12.x] Prevent unnecessary query logging on exceptions with a custom renderer Sep 2, 2025
@luanfreitasdev
Copy link
Contributor Author

luanfreitasdev commented Sep 3, 2025

Another way to validate the memory impact is by simulating it in Tinker. I added a calculation of the $this->queries array size inside onQueryExecuted:

// vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Renderer/Listener.php
public function onQueryExecuted(QueryExecuted $event)
{
    if (count($this->queries) === 100) {
        return;
    }

    $this->queries[] = [
        'connectionName' => $event->connectionName,
        'time' => $event->time,
        'sql' => $event->sql,
        'bindings' => $event->bindings,
    ];

    $size = strlen(json_encode($this->queries)); // added
    $kb = round($size / 1024, 2); // added

    Log::info("Var queries size: {$kb} KB"); // added
}

Run in Tinker to simulate multiple queries:

$i = 0;

do {
    \App\Models\User::query()->whereIn('id', range(1, 200))->first();
    $i++;
} while ($i < 60);

This will trigger 60 queries, and you will see something like this repeated in storage/logs/laravel.log:

// others
[2025-09-03 23:18:03] local.INFO: Var queries size: 153.4 KB  
[2025-09-03 23:18:03] local.INFO: Var queries size: 156.3 KB  
[2025-09-03 23:18:03] local.INFO: Var queries size: 159.19 KB  
[2025-09-03 23:18:03] local.INFO: Var queries size: 162.08 KB  
[2025-09-03 23:18:03] local.INFO: Var queries size: 164.98 KB  
[2025-09-03 23:18:03] local.INFO: Var queries size: 167.87 KB  
[2025-09-03 23:18:03] local.INFO: Var queries size: 170.77 KB  
[2025-09-03 23:18:03] local.INFO: Var queries size: 173.66 KB 

After the change, the $queries variable remains empty when a custom Exception Renderer is present, preventing memory bloat.

@luanfreitasdev luanfreitasdev marked this pull request as ready for review September 3, 2025 23:37
@taylorotwell taylorotwell merged commit b6ecc7d into laravel:12.x Sep 4, 2025
63 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants