Bot / LEX 盤查

它在檢查什麼？
Redis 中 market_status 是「盤口開關」的權威標準， lex:{event_id} 內每個 snapshot 的 state 必須跟齊。
📌 event 基準：掃 exchange_odds:* 拿到要檢查的 event 列表（exchange 沒收的 event 不在 bot 處理範圍）
⚠ 盤口過濾：只比對 LEX/Exchange 支援的 market_id（1x2 / Winner / Handicap / Total 系列；其他 market 屬於正常）
判定規則：
• market_status = 1 → 盤口開放 → LEX 應為 OPEN
• market_status = -1/0/缺 → 盤口關閉 → LEX 應為 SUSPENDED 或無 snapshot
如何閱讀本表？
每列代表 (賽事, product, market_status狀態, LEX狀態) 的不一致組合，market_count 是該組合下有幾個盤口。
👉 點任一列會跳出 modal，列出該組合下的所有問題盤口（market_id / specifiers / 兩邊各自 age）。
常見原因：
• market_status=active + lex=(missing)：LEX 還沒收到 snapshot 或被刪了
• market_status=(missing) + lex=OPEN：通常代表賽事已結束，但 LEX 殘留
• market_status=deactivated + lex=OPEN：盤口被暫停但 LEX 沒同步
關於 age 欄位（為什麼會出現負秒？）
age = 現在時間 − Redis 中該盤口最新一次更新的時間戳。負秒代表 Redis 的時間戳比本機的「現在」**還要晚**，常見原因：
• 時鐘漂移：上游發送端（Sportradar / 撮合引擎）的伺服器時間比本機快幾秒
• 本機時鐘慢：你執行工具的這台機器 NTP 沒同步
一般情況下出現幾秒以內的負值是正常的；如果差到分鐘以上就要檢查兩邊的時鐘

它在檢查什麼？
每筆紀錄是 (某個 agent / bot, 某場 event) 的 pair。 ⚠ 只處理 PG users.bots.status = 'active' 的 bot，inactive 的 bot 自動忽略。
檢查流程：
1. 透過 RiskCtrl gRPC GetSubscriptionList 取出該 agent 訂閱的所有 tournament
2. 透過 GetTournamentList 取出該 agent 對該 tournament 的 gate（trading_tournament_status，ON/OFF）
3. 透過 GetEventList 撈該 tournament 的所有 event
4. 對每場 event 從 Redis 檢查 has_odds / has_open_market / has_bot_quote
本表只列 has_bot_quote=N 的（bot 還沒掛單）。
欄位說明：
• bot_name：bot 名稱（例：bot_TONY01-TONY01），從 PG users.bots 查得；無 PG 連線時為空
• agent_id：訂閱該 tournament 的代理（一個 agent 對應一隻 bot）
• subscribed：該 agent 是否訂閱了這個 tournament（本表都是 Y，因已過濾）
• gate：trading_tournament_status。ON=該 agent 對該 tournament 開閘可以交易；OFF=即使訂閱了，gate 沒開，bot 也不會掛單
• has_odds：exchange_odds:{event_id} 中支援盤口、active=1、且 back_odds>0 或 lay_odds>0 至少一筆 → 源頭真的有掛 back/lay
• exchange_priced_outcomes / exchange_quoted_markets：源頭有報價的 outcome 數 / market 數（=0 表示交易所端沒掛 back/lay，bot 沒掛單就屬正常）
• has_open_market：至少一個 market_status=1 → 有盤口開放
• has_lex_snapshot：lex:{event_id} 有 snapshot → bot 已登錄這場（不代表實際掛單）
• has_bot_quote：Y=所有 OPEN 盤口都有 book 報價；PARTIAL=部分 OPEN 盤口空 book；N=全部 OPEN 都空 book，或根本沒 OPEN
• open_markets：LEX 中 state=OPEN 的支援盤口數
• quoted_markets：上述中 book.runners 有實際 back/lay 報價的數量
• unquoted_open：open_markets - quoted_markets，>0 代表有 OPEN 盤口卻沒掛單
• unwatched_open：unquoted_open 中、bot 連 assigned_market_names（botl:{bot_id}:event_actors）都沒納入的盤口數。代表 bot 根本沒在關注，比單純沒掛單更嚴重。
• assigned_markets_count：bot 對該 event 的 assigned_market_names 個數（=0 通常表示 actor 還沒建起來或抓不到 key）
列出條件：必須 has_odds=Y AND has_open_market=Y（即「該掛」的前提）AND has_bot_quote ≠ Y（包含 PARTIAL 和 N）。 若 odds 或 market 都沒，bot 沒掛是合理的，不列為異常。
• match_status：not_started / live / ended
• phase：PRE 賽前 / LIVE 進行中
• market_age_sec：market_status 最新更新距現在秒數（越大代表資料越舊）
常見原因：gate=OFF（agent 沒開閘）、bot 還沒處理到、bot 卡住、或盤口剛建立 LEX 還沒同步

它在檢查什麼？
每筆紀錄是 (bot, event, market) 三元組：該 event bot 已訂閱、該盤口是 LEX state=OPEN 的支援盤口、 bot 沒掛單，而且該盤口的 key {event_id}:{market_id}:{specifiers} 不在 botl:{bot_id}:event_actors 的 assigned_market_names 裡。
意思是 bot 連「該關注這個盤口」這件事都沒登記，跟「有登記但還沒下單」是不同問題。
常見原因：actor 還沒建起來、bot 卡在 commands/risk wait、或 event_actors key 過期沒更新。
本表為從「Bot 賽事已訂閱但未掛單」展開的盤口 flat 清單，方便定位具體 market。

它在檢查什麼？
跟 Bot 賽事已訂閱但未掛單 邏輯相同，只是檢查對象換成 outright（冠軍 / 期貨，sr:season:xxx）。
每筆 = (bot, season)。透過 RiskCtrl gRPC：
1. GetOutrightSubscriptions → 訂閱的 outright tournament
2. GetOutrightTournaments → 取 gate (trading_tournament_status) + active_seasons[]（含 season_id == event_id）
3. 對每個 sr:season:xxx 從 Redis 看 has_odds / has_open_market / has_bot_quote
列出條件：has_odds=Y AND has_open_market=Y AND has_bot_quote ≠ Y
actor_state 共用 botl:{bot_id}:event_actors，sr:season:xxx 與 sr:match:xxx 同個 hash。
欄位差異：season_id 取代 match_id；start_time 是 season 的 start_date； 不過濾 SUPPORTED_MARKETS（outright market_id 範圍開放）。

指定一個 sr:season:*,列出其底下所有 market×outcome 中:
A 區:bot 沒掛單 且 盤口任一訊號為關閉 (ex_active / market_status / lex.state 三者分開列)。
B-1 區:bot 未訂閱 的 OPEN 盤口 (來自 outright_subscription 的 unwatched_flat,已過濾此 season)。
B-2 區:bot 已訂閱但未報價 的 OPEN 盤口 (rows.unquoted_markets where bot_watching=Y)。
年份過濾:依 seasons.start_date 前綴比對,只在 season 屬於該年才視為命中 (in_year=true)。

它在檢查什麼？
Redis 中只有 lex:{event_id} 有資料，但 exchange_odds、market_status、event_status 三個全部都空的 event。
意義：表示上游（Sportradar / 撮合引擎）已經把這場 event 完全清掉，但 LEX 還殘留 snapshot。
常見原因：賽事已結束太久、Sportradar 主動撤回 event、LEX 清理任務沒執行到、或是賽前準備但 exchange 沒承接
欄位說明：
• LEX snapshot 數：lex hash 內共有幾個 entry
• 支援盤口數：其中屬於支援 market_id（1x2 / Winner / Handicap / Total 系列）的
• state / phase 分布：例如 SUSPENDED:36, OPEN:3 / LIVE:30, PRE:9
• 最新 LEX 時間距今：LEX snapshot 中最近一次更新到現在多久（越久代表殘留越久）