Bounding Execution
Some operations may require significant compute time depending on the complexity of the Terms involved. To prevent excessively long processing, the engine enforces a server-side execution timeout.
The default timeout
Every operation is bounded whether or not you ask for it. When a request carries no executionTimeout, the engine applies the maximum your plan allows, which is 500 ms on the Free plan. No request can run longer than that, so a pathological pattern can never hold a connection open indefinitely.
Execution Timeout
You can lower that ceiling for a single operation by passing a maximum compute time in milliseconds as executionTimeout.
- If the limit is exceeded, the request aborts and returns a
TimeoutExceedederror. - The timeout is enforced server-side, so it bounds compute time rather than the round trip your client observes.
- Asking for more than your plan's maximum is rejected up front with
TimeoutTooLarge.
Lowering the timeout is useful when you process patterns whose complexity you cannot predict and you want them to give up quickly, well before the plan maximum.
Example:
Code
What the budget covers
The timeout bounds everything the server does for one request: reading the Terms you sent, running the operation, and building the response in the format you asked for. Those stages share the budget rather than each getting their own.
That sharing is what makes a heavy operation followed by a regex conversion worth splitting into two calls. See Heavy Operations.