[VicSheCodes]

Why

A review of PR #169 (a canned reply can carry an error status, and the history records it as error) found gaps after it merged, and a review of this branch found three more:

• On Tendermint RPC a canned reply with an error status was recorded as success. The chain wraps a canned body as the result of the reply, and the Tendermint listener had no label rule of its own, so the label read only the body.
• The gRPC listener never reads a canned body. A body under a method name on a gRPC provider was stored and changed no reply. feat(responses): a canned reply can carry an error status, and the history records it as error #169 turned the refusal of an error status there into silent acceptance.
• Tendermint RPC reads http_status as the status of a canned reply, as it reads status, but only status was validated. A text "503" fell back to HTTP 200, and a 302 was sent.
• The tests of the label used bodies that agreed with their status. A rule that also read the body, or that called only 200 a success, passed them.

What changed

• provider_simulator/listeners/tendermint.py: every reply outside 2xx reads error in the history, as on REST and GraphQL: a canned reply, and a reply whose status a provider-wide http_status sets. Inside 2xx the label is unchanged.
• provider_simulator/control_api.py:
  • status and http_status beside a canned body both must be an int from 200 to 299 or from 400 to 599. The message for status keeps the wording of feat(responses): a canned reply can carry an error status, and the history records it as error #169.
  • _a_canned_body_no_endpoint_can_serve refuses a body under a method name on a provider that has a gRPC endpoint and no JSON-RPC, GraphQL or Tendermint RPC endpoint, with HTTP 400 that names the entry, the endpoints of the provider, and the keys a gRPC endpoint reads (result, error, error_stub). A REST [verb, template] entry on a provider with a REST endpoint is accepted. Like the two corruption rules beside it, it reads the endpoints of the provider and no filter.
• Tests:
  • tests/test_listener_tendermint.py: a canned 503 set with status or with http_status reads error, a canned 299 reads success, and a provider-wide http_status of 302 or 503 reads error while 200 reads success.
  • tests/test_control_api.py: a canned body on lava-sim-grpc:1, with status 200 or 503, is refused, and so is a body under a method name on a provider with a gRPC and a REST endpoint. A canned http_status of 302, 100, "503" or true is refused. The controls: a result on the gRPC provider, a canned body on JSON-RPC and on Tendermint RPC, a canned http_status of 503, and a REST pair on the provider with a REST endpoint are accepted.
  • tests/test_simulator_per_method_overrides.py: a canned 503 whose body holds no error reads error, and a canned 299 whose body holds an error reads success.
• Text that feat(responses): a canned reply can carry an error status, and the history records it as error #169 made untrue: two docstrings and one failure message in tests/test_simulator_per_method_overrides.py, the heading in provider_simulator/listeners/jsonrpc.py, the comment above the status check in control_api.py, the Tendermint module docstring, and docs/using_the_simulator.md: the canned reply on each interface, the rule for both status keys, the label of every Tendermint reply, the gRPC refusal, and the canned body in the GraphQL table.

How to verify

pytest tests/test_listener_tendermint.py tests/test_control_api.py tests/test_simulator_per_method_overrides.py -v

Results

• The new Tendermint, gRPC and http_status tests failed before their change: the row read success, and the control API answered HTTP 200 to a gRPC body and to each bad http_status.
• The label tests that pin behaviour feat(responses): a canned reply can carry an error status, and the history records it as error #169 already has passed before the change, and each fails on a broken copy of the code: a label that also needs an error key in the body fails the 503 case, a label that calls 299, or every status but 200, an error fails the 299 case, and a Tendermint label that calls only 400 and up an error fails the 302 case.
• Whole suite, locally: 2566 passed (the 2546 of feat(responses): a canned reply can carry an error status, and the history records it as error #169 plus 20 new cases). black, ruff and mypy: clean.

Not in this pull request

• These settings are accepted and change nothing, for a 2xx canned reply too, before and after feat(responses): a canned reply can carry an error status, and the history records it as error #169: a valid http_status in place of status on JSON-RPC or GraphQL, a status with no body, and a window such as fail_first_n beside a canned reply, which the canned branch never reads.
• On JSON-RPC a reply that the chain builds is labelled by its body, so a provider-wide http_status outside 2xx with a result body reads success there, and error on Tendermint RPC, REST and GraphQL.
• A WebSocket frame has no HTTP status. A canned reply with an error status sends its body in the frame, and the row reads error.