[Bug]: Occasional `TooManyCallsException`

[sit-fricke]

What happened?

When using the icon-picker in a form I regularly encounter a Livewire\Exceptions\TooManyCallsException exception:

Too many method calls in a single request (184). Maximum allowed is 50. You can configure this limit in config/livewire.php under 'payload.max_calls'.

I have identified 3 factors that make the problem more probable:

• when using the iconsSearchResults(false) mode
• when scrolling the search-results really fast
• on big screens, when the dropdown is wider and thus shows more icons at once

In case its important: I'm using the blade-google-material-design-icons.

How to reproduce the bug

1. Place the picker in a form
2. Apply the iconsSearchResults(false) option
3. Open the form in the browser
4. Expand the dropdown and scroll through the icons really fast

-> The mentioned Error-Message pops up + the icons affected by the error are not loaded.

Workaround

Apply the suggested config payload.max_calls, though this is not desirable, since in extreme situations the request count can exceed 400% of the default limit.

Package Version

4.0.0

PHP Version

8.4.17

Laravel Version

11.48.0

Which operating systems does with happen with?

Linux

Notes

Im using

• laravel/sail@1.52.0 with modified Docker-Image
• filament/filament@5.1.1 (livewire/livewire@4.1.0)

[akzize]

try this out
Open config/livewire.php. If it does not exist, publish it using:
php artisan vendor:publish --tag=livewire:config

set payload.max_calls to 300 or more

'payload' => [
    'max_calls' => 300,
],

[elalaoui1]

try this out Open config/livewire.php. If it does not exist, publish it using: php artisan vendor:publish --tag=livewire:config

set payload.max_calls to 300 or more

'payload' => [
    'max_calls' => 300,
],

thanks man it's work

[sit-fricke]

try this out Open config/livewire.php. If it does not exist, publish it using: php artisan vendor:publish --tag=livewire:config

set payload.max_calls to 300 or more

'payload' => [
    'max_calls' => 300,
],

This is just a workaround, not a solution. There is a reason that level is set this way by default.

Quote from the config file:

These settings protect against malicious or oversized payloads that could cause denial of service. The default values should feel reasonable for most web applications.