Crawl4AI accepted unbounded delay parameters and occupied browser capacity

The browser service capped normal page-load waits, but request settings governing delays before returning HTML and delays between operations did not share those limits. A caller could submit enormous values, including around one billion seconds, without triggering the page timeout validator. Long-lived stream handling created a separate resource-retention path from the ordinary bounded request endpoint.

This was not a slow backend inadvertently keeping the connection open. The service had accepted an intentional caller-controlled wait and kept scarce browser capacity committed to it. Concurrent users could then lose availability even though the standard page-load timeout looked reasonable in configuration.

The 0.9.5 fix reportedly bounds delay values, including malformed negative and non-finite numbers. Useful acceptance tests must run concurrent streaming and non-streaming requests, then verify worker reclamation after cancellation or disconnection. Limiting one duration field does not constrain the sum of independently configurable delays across a complex tool call.