Problem
The in-memory Order Book accumulates resting orders across test runs
on the live Railway environment. When running sequential test scenarios,
orders from previous scenarios remain in the Order Book and cause
unexpected matches in subsequent tests.
Example
Scenario 3 (No Match, price gap Buy@90 vs Sell@100) produced incorrect
results because a resting Buy@100 from Scenario 2 (Partial Fill) was
still in the Order Book and matched the incoming Sell@100.
Root Cause
OrderBookRecoveryService reloads all Pending and PartiallyFilled orders
from the database on startup. Between test runs, these orders persist in
PostgreSQL and are reloaded into memory on every redeploy.
Workaround
See README.md -- Database Reset (Railway) section.
Clean the database in the correct FK order, then redeploy the backend.
Proper Fix
Implement integration tests using xUnit with an in-memory database and
a fresh OrderBook instance per test. No shared state, no Railway dependency.
Problem
The in-memory Order Book accumulates resting orders across test runs
on the live Railway environment. When running sequential test scenarios,
orders from previous scenarios remain in the Order Book and cause
unexpected matches in subsequent tests.
Example
Scenario 3 (No Match, price gap Buy@90 vs Sell@100) produced incorrect
results because a resting Buy@100 from Scenario 2 (Partial Fill) was
still in the Order Book and matched the incoming Sell@100.
Root Cause
OrderBookRecoveryService reloads all Pending and PartiallyFilled orders
from the database on startup. Between test runs, these orders persist in
PostgreSQL and are reloaded into memory on every redeploy.
Workaround
See README.md -- Database Reset (Railway) section.
Clean the database in the correct FK order, then redeploy the backend.
Proper Fix
Implement integration tests using xUnit with an in-memory database and
a fresh OrderBook instance per test. No shared state, no Railway dependency.