What is this task and why do we need to work on it?
HotShot needs an API of some kind to mimic the behavior of the solver in a controllable way. Specifically, we need to be able to construct payloads that can simulate what we might get from the Solver, and also construct special payloads that may fail, or be too large, or not show up at all. This will enable us to have more resilient testing across a number of situations.
The logic is relatively straightforward, we’ll make available some placeholder endpoint which will spawn transactions. We’ll use the test interface for the AuctionResults type to pull in the data during the test, and we’ll make some query flags available that will not exist in the final system to inject different outcomes into the system (things like spurious failures, etc).
import fastapi
from typing import Union
app = fastapi.FastAPI()
@app.get("/")
def read_root(
# Fail to reply
fail: Union[bool, None],
# Delay some random amount between 0 and max timeout (1 second).
random_delay: Union[bool, None],
):
return get_fake_solver_results()
This testing script will be utilized to vet the various solver functionality and outage situations. Solver outages will be treated as empty blocks, and the failures should be handled gracefully in the event of no data being present. This script’s lifecycle will be dictated by the test using std::process::Command.
What work will need to be done to complete this task?
No response
Are there any other details to include?
No response
What are the acceptance criteria to close this issue?
The MockAPI is implemented and runs in a stable fashion during the integration tests.
Branch work will be merged to (if not the default branch)
What is this task and why do we need to work on it?
HotShot needs an API of some kind to mimic the behavior of the solver in a controllable way. Specifically, we need to be able to construct payloads that can simulate what we might get from the Solver, and also construct special payloads that may fail, or be too large, or not show up at all. This will enable us to have more resilient testing across a number of situations.
The logic is relatively straightforward, we’ll make available some placeholder endpoint which will spawn transactions. We’ll use the test interface for the AuctionResults type to pull in the data during the test, and we’ll make some query flags available that will not exist in the final system to inject different outcomes into the system (things like spurious failures, etc).
This testing script will be utilized to vet the various solver functionality and outage situations. Solver outages will be treated as empty blocks, and the failures should be handled gracefully in the event of no data being present. This script’s lifecycle will be dictated by the test using std::process::Command.
What work will need to be done to complete this task?
No response
Are there any other details to include?
No response
What are the acceptance criteria to close this issue?
The MockAPI is implemented and runs in a stable fashion during the integration tests.
Branch work will be merged to (if not the default branch)
No response