# Update of API/serialization time constraints for nodeos 5.0

Requirements:
- an API node should be able to serve any `atomic` request (such as `get_block`, `send_transaction*` and `push_transaction*`) successfully
- for non `atomic` API calls, such as `get_table_rows`, `get_table_by_scope`, `get_scheduled_transactions` and `get_producers` (where the user is free to request a smaller range if needed), the node operator should be able to specify a max request time.
- some specific (user-provided) ABIs can be crafted to take an excessively long time (abi-bombs), and we must guard against that.

## ABI serialization limit

In 5.0, the ABI deserialization for most ABI intensive requests (including `get_block`, `send_transaction*`, `push_transaction*`, `get_account`, `get_table_rows`) was moved to the HTTP thread pool, so ABI deserialization no longer can affect the responsiveness of nodeos's main thread.

Note that ABI serialization, when processing the API parameters (for example for `send_transaction2`), still occurs on the main thread and is limited by `abi-serializer-max-time-ms`. In case of serialization failure, the API will fail and return an error.

For the deserialization now occuring on the http thread pool, any single deserialization call will be limited by `abi-serializer-max-time-ms` as well. If that limit is hit for a specific object, the request will not fail, instead that object will be returned in the binary, non-deserialized form.

So when processing a request such as `get_block`, the request will always succeed (no timeout), but some specific objects may be returned in non-deserialized form. The max time for processing a `get_block` request will only be limited by the maximum number of actions in a block and `abi-serializer-max-time-ms`.

However because the deserialization is now done off the main thread, the absence of a lower limit should not impact the responsiveness of the node when serving legitimate requests.

## Constraints on the number of items returned for non-atomic APIs

`http_max_response_time` now applies only to requests which specify a range of objects to be retrieved ( `get_table_rows`, `get_table_by_scope`, `get_scheduled_transactions` and `get_producers`), and specifies the maximum time spent on the main thread.

As before, API requests can also specify an optional `time_limit_ms` which now also provides a constraint on the maximum time spent on the main thread (excluding deserialization).

As long as the request is valid and the requested range is not empty, a minimum of one object will always be returned (one row for `get_table_rows` for example). There is also a hard coded maximum of 1000 items returned, unless `http_max_response_time` is set to `-1` in which case there is no limit.

So we define:
* **`max_time`** is the minimum of `http_max_response_time` and `time_limit_ms` (negative values are equivalent to infinite time).
* **`max_items`** is the requested range size, limited to 1000 unless `http_max_response_time` is negative.
* **`min_items`** is 1 if the requested range is not empty, 0 otherwise

API processing occurs in two steps:

1. On the main thread, retrieval (in binary format) of as many requested items as possible within the range [**`min_items`**, **`max_items`**], with a **`max_time`** processing limit.
2. On the http thread pool, formatting of the http response, including the ABI deserialization of every object that can be deserialized within`abi-serializer-max-time-ms`, and returning the response.

> note: if `http_max_response_time` is set to `-1` and the request does not set a `time_limit_ms`, the request will always return the complete requested range.

> note: the protection against ABI bombs described above still applies, so if any specific object deserialization takes longer than `abi-serializer-max-time-ms`, it will be returned in binary form. Unlike prior behavior, this will not cause the request to fail and return an error code.

> note: another change from previous behavior is that `http_max_response_time` now applies exclusively to the time spent on the main thread. If left unchanged, a node running 5.0 will be able to serve larger API requests than a 4.0 node.