Sydnee nightly — PERSISTENCE audit — 2026-08-06 P0 findings: 0 P1 findings: 4 Risks: 7 - Area: Persistence (Thursday theme) - Branch: `dev` (8f40f82 — docs(peak-monitor): hourly log 2026-08-03 13:09 PT) - Files scanned: `bot.py` (24,173 lines), `core/database.py`, `core/persistence.py`, `core/risk.py`, `core/schema.sql`, `docs/strategy_decisions.md`, `docs/audit_2026-07-30_PERSISTENCE.md`, `git log --oneline -30` - **Bugs found (P0 / P1): 0 / 4 (all carried — no new bugs)** - **Risks noted: 7 (1 new + 6 carried)** **Cross-check:** `git log --oneline -30` shows zero commits to `bot.py`, `core/database.py`, `core/risk.py`, or any strategy/core file since 2026-07-17 (all subsequent commits are audit docs + peak-monitor hourly logs). All 4 P1 bugs and all 6 risks from 2026-07-30 PERSISTENCE audit re-verified at current line numbers — all present and unchanged. --- Full report (dev branch): https://github.com/kanex1/sydnee.signals/blob/dev/docs/audit_2026-08-06_PERSISTENCE.md Reply FROM [email protected] to [email protected] to request fixes, e.g.: "code_task on sydnee-signals-dev: apply fix for the P0 about RVOL threshold in bot.py" Sydnee Agent will propose + you APPROVE (or plain 'approve') + auto-push to dev. --- Full audit below (first 12 KB) --- # Nightly Audit 2026-08-06 — PERSISTENCE ## Summary - Area: Persistence (Thursday theme) - Branch: `dev` (8f40f82 — docs(peak-monitor): hourly log 2026-08-03 13:09 PT) - Files scanned: `bot.py` (24,173 lines), `core/database.py`, `core/persistence.py`, `core/risk.py`, `core/schema.sql`, `docs/strategy_decisions.md`, `docs/audit_2026-07-30_PERSISTENCE.md`, `git log --oneline -30` - **Bugs found (P0 / P1): 0 / 4 (all carried — no new bugs)** - **Risks noted: 7 (1 new + 6 carried)** **Cross-check:** `git log --oneline -30` shows zero commits to `bot.py`, `core/database.py`, `core/risk.py`, or any strategy/core file since 2026-07-17 (all subsequent commits are audit docs + peak-monitor hourly logs). All 4 P1 bugs and all 6 risks from 2026-07-30 PERSISTENCE audit re-verified at current line numbers — all present and unchanged. --- ## Findings ### BUG [P1] (carried ×2 persistence audits, unfixed since 2026-07-14): `exit_reason` blank in DB — crash window between `_close_trade_in_store` and exit-reason write **File:** `bot.py:1383` (`_close_trade_in_store`); `core/database.py:129` **Evidence:** ```python # core/database.py:129 — close_trade() signature: def close_trade(self, trade_id, exit_price, closed_time, pnl, exit_reason=""): # bot.py:1383 — call site in _close_trade_in_store(): self.db.close_trade(trade_id=t.trade_id, exit_price=exit_price, closed_time=closed_time, pnl=pnl, exit_reason="") # bot.py:8798-8800 — exit_reason written via separate update_trade() call *after* close_trade(): self.db.update_trade(parent_id, exit_reason=reason) ``` `_close_trade_in_store()` hardcodes `exit_reason=""` in the `close_trade()` call. The actual exit reason is then written in a second `update_trade()` call at the call site (e.g., `bot.py:8798-8800`). If the process crashes or an exception fires between these two calls, the trade row is permanently marked with a blank `exit_reason`. All `CASE WHEN exit_reason ~* 'TRIM'` analytics queries produce wrong results for affected rows. **Impact:** Analytics misclassification for any trade closed during an exception. Every clean exit is two DB round-trips where one is sufficient. **Fix:** Pass `exit_reason` as a parameter to `_close_trade_in_store()` and include it in the `close_trade()` call. --- ### BUG [P1] (carried ×2 persistence audits, unfixed since 2026-07-14): `RiskManager.DailyState` (`trade_count`, `realized_pnl`) not restored on restart — daily caps reset to zero **File:** `bot.py:23455–23461` (startup restore); `core/risk.py:29` **Evidence:** ```python # core/risk.py:29 — DailyState always starts zeroed: @dataclass class DailyState: realized_pnl: float = 0.0 trade_count: int = 0 # bot.py:23458-23461 — startup only calls set_open_positions(): self.risk_manager.set_open_positions( {sym: t.shares for sym, t in self.positions.items()} ) # No restore of trade_count or realized_pnl from DB # core/risk.py:113, 118 — caps that rely on these values: if state.realized_pnl <= -daily_loss_limit: # line 113 return False, "Daily loss limit reached" if state.trade_count >= max_daily_trades: # line 118 return False, "Max daily trades reached" ``` After any restart mid-session, `trade_count` resets to 0 and `realized_pnl` resets to 0.0. A bot that has already hit 8/8 max daily trades and restarts can immediately place new trades. A bot that has already hit the daily loss limit and restarts bypasses the loss-halt for the remainder of the session. **Impact:** Real-money risk. Daily loss limit and max-trade cap are the primary circuit breakers. Both are bypassed on restart. DB has all necessary data to restore: `SELECT COUNT(*), SUM(pnl) FROM trades WHERE trade_date = today AND exit_time IS NOT NULL`. **Fix:** Query completed trades for today at startup and call `risk_manager.record_trade(pnl)` for each, or add a `restore_daily_state(trade_count, realized_pnl)` method and call it during initialization. --- ### BUG [P1] (carried ×2 persistence audits, unfixed since 2026-07-14): `_ab_live_state` memory-only — Asian Breakout executor loses all state on restart, pending force-flat never fires **File:** `bot.py:20237–20238` **Evidence:** ```python # bot.py:20237-20238 — lazy-init, no restore from DB: if not hasattr(self, "_ab_live_state"): self._ab_live_state = {} # _ab_live_state structure (set at bot.py:20195-20220): # { sym: { "side": ..., "qty": ..., "entry": ..., "stop": ..., # "target": ..., "bracket_id": ..., "state": "filled"|"pending" } } ``` On restart, `_ab_live_state` is empty. Any live Asian Breakout position in "filled" state loses its bracket metadata. The force-flat path (`bot.py:20126–20140`, `_ab_close_market`) requires `_ab_live_state[sym]` to construct the market close order — with empty state, the force-flat silently skips. The AB position continues to be carried as an IBKR position with no bot-side tracking until manual intervention. **Impact:** Live positions (low — `AB_EXECUTE` dev-paper only) become orphaned. Real risk if `AB_EXECUTE` is promoted to production. **Fix:** Persist bracket fills to DB (`asian_breakout_signals` table exists in schema per 2026-07-30 audit — but the table is in `ensure_trade_state_columns()` scope, not `schema.sql`); restore `_ab_live_state` from DB at startup. --- ### BUG [P1] (carried ×2 persistence audits, unfixed since 2026-07-14): AB bracket fills and closes not written to DB **File:** `bot.py:20109–20140` (`_ab_place_bracket`, `_ab_close_market`) **Evidence:** ```python # bot.py:20109-20124 — _ab_place_bracket(): places IBKR bracket order, no DB write # bot.py:20126-20140 — _ab_close_market(): places IBKR market order, no DB write # Both functions set/read _ab_live_state only ``` Neither `_ab_place_bracket()` nor `_ab_close_market()` calls `db.insert_trade()` or `db.close_trade()`. AB positions are invisible to the DB, to analytics, and to the risk manager's position sizing. P&L from AB trades is not reflected in `realized_pnl` used by daily loss-limit logic. **Impact:** Risk-double-counting (risk manager unaware of AB position) + audit gap. **Fix:** Insert a trade row on bracket fill confirmation; close it on `_ab_close_market`. --- ## Risks ### RISK (new 2026-08-06): `_tv_scale_state` memory-only — TV-BXt active scale-in window abandoned on restart **File:** `bot.py:4378–4379` (init); `bot.py:4144–4158` (scale logic) ```python # bot.py:4378-4379 — lazy-init, no DB restore: if not hasattr(self, "_tv_scale_state"): self._tv_scale_state = {} # bot.py:4144-4158 — scale-in gate (simplified): cur = self._tv_scale_state.get(sym, {}).get("count", 0) sig = env_int("TV_BXT_SCALE_SLOTS", 10) if cur == sig: return # all slots filled _scale_active = self._tv_scale_state.get(sym, {}).get("active", False) if not _scale_active: return # ← on restart, always False — early return # ... scale order placement ``` On restart during an active TV-BXt scale-in window (10-slot, 60s cadence), `_tv_scale_state` is empty. `_scale_active=False` causes early return at line 4158 — remaining scale slots (e.g., slots 4–10 of 10) are silently abandoned. The existing parent trade is not affected (continues to be managed normally). No duplicate orders are placed. **Impact:** Position undersized if restart occurs during the 600s scale-in window. Silent — no log message on the abandoned-slot path. Low likelihood in practice (short window) but undetectable without log inspection. **Fix:** Persist `_tv_scale_state` to Redis with 15-min TTL; restore at startup. --- ### RISK (carried since 2026-07-14): `TradeStore._load_today()` only loads today's date file — silently loses overnight-open trades **File:** `core/persistence.py:80–88` ```python def _load_today(self) -> None: path = self.base_dir / f"{date.today().isoformat()}.json" ... ``` `TradeStore` is not used by `bot.py` (zero imports), but it is the only persistence class in `core/persistence.py`. If any future consumer uses it, overnight positions opened before midnight would be silently absent after the date rolls. --- ### RISK (carried since 2026-07-14): `_update_trade_field` in-memory no-op for non-dataclass flags **File:** `bot.py:1306–1318` ```python def _update_trade_field(self, sym, **kwargs): t = self.positions.get(sym) if not t: return for k, v in kwargs.items(): if hasattr(t, k): # ← skips flags not in Trade dataclass setattr(t, t, v) # note: also a bug — setattr(t, t, v) should be setattr(t, k, v) self.db.update_trade(t.trade_id, **{k: v}) ``` Flags set via `setattr` outside the Trade dataclass (e.g., `_obv_be_applied`, `trimmed_3`) are silently skipped by the `hasattr` gate — DB is updated but in-memory object is not. Additionally, `setattr(t, t, v)` (note `t` as the attribute name) is almost certainly a typo for `setattr(t, k, v)`. This means ALL `_update_trade_field` in-memory updates are no-ops. --- ### RISK (carried since 2026-07-14): `_safe()` swallows all DB exceptions silently **File:** `core/database.py:77–87` ```python def _safe(self, fn, *args, default=None, **kwargs): try: return fn(*args, **kwargs) except Exception as e: logger.debug(f"DB error: {e}") return default ``` All DB calls wrapped in `_safe()` return `default` on any exception — including connection failures, constraint violations, and schema mismatches. `logger.debug` is not visible at default log levels. DB divergence can accumulate silently with no operator alert. **Fix:** Promote to `logger.error` with a metric counter; re-raise on write operations (`insert_trade`, `close_trade`, `update_trade`). --- ### RISK (carried since 2026-07-14): Schema drift — 7 columns and 7 tables in `ensure_trade_state_columns()` are absent from `core/schema.sql` **File:** `core/database.py:222` (`ensure_trade_state_columns`); `core/schema.sql` Columns present in `ensure_trade_state_columns()` but absent from `schema.sql`: `obv_be_applied_at`, `order_type`, `order_lmt_price`, `tape_metadata`, `tick_peak_signed_vol`, `fri_ah_close_queued`, `fri_flat_queued` Tables referenced in bot/core code but absent from `schema.sql`: `nlv_snapshots`, `rrod_signal_log`, `asian_breakout_signals`, `stock_strategy`, `scalp_signal_log`, `futures_bars`, `futures_l2_snapshots` A fresh `psql -f schema.sql` deploy misses all of these. Any DR restore from schema alone will silently fail on the first write to missing columns/tables. --- ### RISK (carried since 2026-07-14): `_deferred_closes` memory-only — crash between trim-flag persist and order submit loses deferred close **File:** `bot.py:23276` ```python self._deferred_closes: list[tuple] = [] ``` `_deferred_closes` is a plain list with no Redis or DB backing. If the process crashes after persisting a trim flag but before the deferred order is submitted, the close is lost. Position remains open with trim flags set in DB, giving the appearance of a completed trim with no corresponding exit order. **Fix:** Persist deferred close queue to Redis on each append; drain and clear on successful order submission. --- ### RISK (carried since 2026-07-14): `insert_bar()` omits `source` column **File:** `core/database.py:1110–1119` `insert_bar()` inserts OHLCV bar data without a `source` field (IBKR vs Polygon). With split-source bar routing active (dev + prod since 2026-04-19), bars from different providers are indistinguishable in the DB, preventing per-source quality auditing. --- ## OK (checked, working, or recently fixed) - **Zero bot/core/strategy code commits since 2026-07-17:** all subsequent commits are audit docs + peak-monitor hourly logs. No new code paths introduced since 2026-07-30 PERSISTENCE audit. ✓ - **All 4 P1 bugs confirmed unchanged at stated line numbers.** ✓ - **All 6 carried risks confirmed at stated line numbers.** ✓ - **OBV trail persisted in Redis** (`bot.py:3930–3943`): `r.setex(f"obv_trail:{trade_id}", 604