Like @prudloff, we ran into the same issue.
The basic example is any controller that returns a render array. If a bot hits that route with unique query strings, it will create a new cache_page record, if that bot hammers on the page consistency, you end up with tens or even hundreds of gigabytes of data because the entire page is stored even with the same content. This is namely the Internal Page Cache module that is causing the issue.
"database_cache_max_rows" doesnt work like prudloff mentioned because those max rows are only restricted on a cron run. So by the time the cron runs the site dies because there are too many records to restrict and delete old records.
We had similar solution ideas with Redis cache, or rate limits. Rate limits is a bit concerning of a solution as it could potentially rate limit a legitimate web crawler.
The primary issue on our server is the site would die on cron runs, so we clear cache before a cron run nightly. A cache clear runs at a good speed versus the db row constrain from cron. Probably because a cache clear is a simple quick truncate of the cache tables.
On the commit from #8, I got it working by changing:
```
return $element['#default_value'] ? (string) $element['#default_value'] : NULL;
```
To
```
return isset($element['#default_value']) && is_scalar($element['#default_value']) ? (string) $element['#default_value'] : NULL;
```
Its an odd situation, the main issue comes from the core\lib\Drupal\Core\Form\FormBuilder
```
// Final catch. If we haven't set a value yet, use the explicit default
// value. Avoid image buttons (which come with garbage value), so we
// only get value for the button actually clicked.
if (!isset($element['#value']) && empty($element['#has_garbage_value'])) {
$element['#value'] = $element['#default_value'] ?? '';
}
```
Where default_value is interpreted as a integer. Probably a better solution somewhere else to make sure default_value is cast as a string? Didnt have more time to look into this.
Sorry Abramm you are correct, just really running into these issues now at Drupal 9.5 after never having issues for years. I think many older tutorials make it vague and like its an either/or type of situation where attaching context to listeners is a magic bullet that is really not the case anymore (EX: https://www.lullabot.com/articles/understanding-javascript-behaviors-in-...)
I agree with #7, we have to make a conversion to make this work as well. It was a very easy to understand the concept before of attaching listeners to the context parameter (new html will flow through context once), but now being require to use once() adds additional complexity and boilerplate code.