Primary finding
BasePlatform reuses single shared `db_cursor` from background loop, but other handlers also call `_execute_db_command` — concurrent reads will clobber cursor state
- backend/wonderwall/simulations/base.py:204-215
- backend/wonderwall/simulations/polymarket/platform.py:237-260
Although the message loop processes one message at a time (so cursor reuse appears safe within a single handler), `update_rec_table` and other async hooks could be invoked elsewhere. Also, the handler uses `self.db_cursor.fetchone()` immediately after `_execute_db_command` for one query, then another `_execute_db_command` overwrites the cursor state for the next read. This is correct sequentially but if any awaited code between two `_execute_db_command` calls re-enters the platform (e.g., during testing/mocks), the second `_execute_db_command` will clobber pending rows. Multiple sequential reads pattern is brittle.
Recommendation
Use `conn.cursor()` per query (or per handler) instead of a shared cursor. SQLite Python cursors are lightweight.