布到根因閉環(huán)的完整實施指南)
DeepSeek-Reasonix Desktop 崩潰診斷運行手冊從 Firebase Spark 發(fā)布到根因閉環(huán)的完整實施指南【免費下載鏈接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.項目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix本手冊面向負責 DeepSeek-Reasonix 桌面端Windows/Linux崩潰診斷鏈路的運維與研發(fā)人員完整覆蓋診斷數據的發(fā)布順序、Spark 容量預算、隱私合規(guī)、性能門禁、跨平臺能力認證矩陣以及根因閉環(huán)判定標準。閱讀本文后你將掌握如何在不依賴 Cloudflare 付費服務的前提下以「D1 → dual → firebase」三段式滾動切換完成崩潰報告的采集、投遞與審計歸檔并能依據明確的指紋fingerprint影響率證據決定何時發(fā)布定向補丁。手冊定位診斷鏈路是一套可發(fā)布、可回滾的工程系統(tǒng)跨平臺 Desktop 診斷鏈路涉及客戶端上報、Cloudflare Workers 接收、D1 聚合存儲與 Firebase Realtime Database 樣本歸檔多個環(huán)節(jié)其發(fā)布、隱私、性能與根因調查必須形成閉環(huán)。本手冊強調兩點前提Windows build17763Windows 10 LTSC 2019是重點實驗環(huán)境而不是代碼白名單——它代表最老、能力最受限的運行時組合用于暴露兼容性問題發(fā)布診斷版本本身不代表問題已經解決。診斷鏈路的每個版本都必須經歷 7 天完整 UTC 日對比、能力矩陣驗收與根因證實之后才允許進入正式 feature release。整套鏈路的核心代碼位于 workers/crash-reportCloudflare Worker與 desktop桌面端 Go 宿主本手冊即圍繞這兩部分的聯(lián)調發(fā)布展開。發(fā)布順序十二步從零搭建到穩(wěn)定觀察1. 隔離的 Firebase Spark 項目Firebase 項目必須保持Spark免費層且不關聯(lián) Cloud Billing只在asia-southeast1區(qū)域創(chuàng)建 Realtime Database并部署 workers/crash-report/firebase/database.rules.json。該規(guī)則文件內容為{ rules: { .read: false, .write: false } }即客戶端對數據庫的讀寫均被拒絕——所有數據寫入只允許通過 Worker 的服務端憑據完成。不得啟用 Functions、Firestore、BigQuery、Hosting、Storage 或 Secret Manager 中任何一項將攻擊面與費用面同時壓到最小。2. 倉庫 Secret 與服務賬號最小授權在倉庫 Actions Secrets 中配置三個 SecretSecret 名稱用途FIREBASE_DATABASE_URLRealtime Database 實例地址FIREBASE_CLIENT_EMAIL專用服務賬號郵箱FIREBASE_PRIVATE_KEY服務賬號私鑰服務賬號必須專用于 crash 投遞且僅授予 Realtime Database 權限不得附帶其他 Google Cloud 權限。嚴禁使用 Web Firebase 配置也不得在 Desktop 產物中攜帶 Firebase SDK 或任何配置——客戶端完全不接觸 Firebase。3. 凍結候選 SHA唯一候選提交 SHA 一經選定即凍結已發(fā)布的 tag 不得移動或重建保證后續(xù)所有構建、遷移與對比基于同一份代碼。4. 備份 D1 并執(zhí)行 diagnostics-v2 遷移先備份 D1再運行npm run migrate:diagnostics-v2該命令由 workers/crash-report/scripts/apply-diagnostics-v2.mjs 實現會在寫入前記錄新的 D1Time Travel bookmark見腳本中對wrangler d1 time-travel info的調用隨后應用 workers/crash-report/migrate-diagnostics-v2.sql。該遷移是純增量additive的reports表新增webview2、web_runtime兩列pings與cli_pings新增os_build、os_revision、channel、distro_id、distro_version、kernel_version、session_type、runtime_engine、runtime_version、gpu_mode等跨平臺歸屬列新建聚合表report_daily、report_installations、report_event_dimensions及配套索引fingerprint/date新建diagnostics_meta元數據表并寫入installation_linked_since鍵。已退休的metric_users和cli_metric_users在 #9379 中退役不再是必需表不得重建。關鍵約束活躍 diagnostics 表出現任何 partial部分缺失狀態(tài)時仍然 fail closed——遷移腳本會在寫入前檢查完整 schema缺一半就拒絕執(zhí)行絕不帶著殘缺結構上線。5. 執(zhí)行 Firebase crash 遷移運行npm run migrate:firebase-crash實現見 workers/crash-report/scripts/apply-firebase-crash.mjs。流程為先記錄 D1 Time Travel bookmark再依次應用第一階段 workers/crash-report/migrate-firebase-crash.sql 與第二階段 workers/crash-report/migrate-firebase-crash-capacity.sql任一階段部分完成時 fail closed腳本用classifyFirebaseCrashSchema將表/索引狀態(tài)歸類為complete/absent/partial遇到partial直接拋錯終止。第一階段創(chuàng)建三類核心結構firebase_crash_outbox投遞隊列state限定queued/processing/projected配套firebase_crash_outbox_retry重試索引firebase_crash_receipts投影回執(zhí)記錄group_count、latest_slot、first_samplefirebase_crash_group_leases舊版租約表僅用于滾動部署兼容新邏輯使用firebase_crash_group_state。遷移前還會執(zhí)行 Spark 容量預檢firebaseCrashCapacityQuery按 groups 表的status與last_seen估算預留字節(jié)超過 700 MiB 直接拒絕。遷移后需驗證 outbox、receipt、兼容 lease 表、firebase_crash_group_state及全部投遞/生命周期索引齊全。6. 驗證診斷聚合對象確認以下對象存在且結構正確report_daily、report_installations、report_event_dimensions、diagnostics_meta、fingerprint/date 索引、ping 窗口索引以及installation_linked_since鍵值。7. GitHub Actions 雙階段部署dry-run 先行在Actions Deploy crash worker Run workflow中選擇main-v2分支并將Firebase crash history operation設為dry-run任務使用現有倉庫 Secret經canaryenvironment 審批不會部署 Worker腳本按每頁 200 個 fingerprint的 keyset 分頁讀取歷史數據PAGE_SIZE 200逐頁評估遷移容量預計預留必須不超過 700 MiB日志只輸出計數、fingerprint 前綴和摘要絕不落原始樣本。確認 dry-run 結果后重新觸發(fā)并將操作設為apply輸入精確確認短語APPLY_FIREBASE_CRASH_DATA任務會在同一 runner 內依次執(zhí)行--apply與--verify-only保證寫入后立即核驗。后續(xù)獨立核驗可單獨選擇verify-only。已認證的運維人員仍可在本機直接運行實現見 workers/crash-report/scripts/migrate-firebase-data.mjsnpm run migrate:firebase-data # 評估模式 npm run migrate:firebase-data -- --apply # 執(zhí)行遷移 npm run migrate:firebase-data -- --verify-only # 只核驗遷移默認 checkpoint 為權限0600且已 gitignore 的.firebase-crash-migration-state.json可用--checkpointpath改路徑只有明確重跑時才使用--reset-checkpoint。腳本內部以服務賬號私鑰簽發(fā) JWTurn:ietf:params:oauth:grant-type:jwt-bearer換取 OAuth token并對每個事件生成確定性的sha256(firebase-migration\nfingerprint\nid)前 32 位作為eventId確保可重復執(zhí)行不產生重復數據。8. Worker 以 dual 模式做 smokeWorker 先使用dual模式部署workers/crash-report/wrangler.toml 中CRASH_STORAGE_MODE d1為安全默認值需顯式改為dual。用舊 Report/Ping/Metrics 報文、legacywebview2、Windows/LinuxwebRuntimepayload 做channeltest的 smoke 測試。channeltest流量始終落入 development namespace——workers/crash-report/src/diagnostics_v2.ts 中developmentGroupSQL groups.fingerprint LIKE dev:%測試指紋以dev:前綴隔離絕不混入 release 崩潰優(yōu)先級index.test.ts中也有keeps development reports out of release crash priority用例保障。9. 七整日影子對比后切換 firebase連續(xù)比較7 個完整 UTC 日fingerprint、計數、樣本和脫敏結果一致后才把CRASH_STORAGE_MODE從dual切換為firebase。Firebase 模式下 D1 只保留聚合、索引和有界 outbox不再寫入新reports原文。模式枚舉定義在 workers/crash-report/src/crash_delivery.tsd1 | dual | firebase非法值直接拋錯。10. 簽名構建與 feature release用同一 SHA 生成簽名 Windows/Linux 構建能力矩陣與性能門禁見下文全部通過后才發(fā)布 feature release。11. 歸檔舊樣本并保留三模式回滾穩(wěn)定觀察 7 天后歸檔 D1 舊原始樣本。保留d1、dual、firebase三種回滾模式Worker 回滾不要求客戶端升級——因為模式只是 Worker 側配置客戶端上報協(xié)議不變。12. 管理界面審計整理通過管理界面整理歷史數據忽略[go panic] safe/v9.9.9等已知噪音將72daba81標記為在desktop-v1.19.3解決忽略舊desktop.abnormal_exitreplay 分組保證審計視圖聚焦真實問題。Spark 容量、生命周期與回滾700 MiB 固定預算Worker 固定執(zhí)行 700 MiB 預留上限workers/crash-report/src/crash_delivery.ts 中FIREBASE_STORAGE_BUDGET_BYTES 700 * 1024 * 1024按樣本狀態(tài)分檔預留樣本狀態(tài)每組預留說明active640 KiB活躍分組全量樣本compacted128 KiB壓縮后的 marker 樣本archiving32 KiB歸檔過渡期archived0已歸檔不占預算達到 80% 時FIREBASE_STORAGE_WARNING_BYTES復用現有 webhook 告警并在后臺提示新組或擴容會越過上限時必須在創(chuàng)建 outbox 前返回503見reserveFirebaseGroup的容量條件。該上限是硬約束不得改為可配置項。生命周期狀態(tài)機只有resolved/ignored分組參與生命周期workers/crash-report/src/firebase_lifecycle.ts 的runFirebaseCrashLifecycle三階段30 天最近 5 個樣本替換為帶 fencing租約代際的 marker保留當前 sample epoch 首個樣本狀態(tài)active → compacted60 天tombstone 全部樣本路徑狀態(tài)compacted → archivingarchiving 滿 24 小時條件刪除 Firebase groupdeleteFirebaseCrashGroupConditional狀態(tài)archiving → archived。D1 側的計數、狀態(tài)、備注、聚合和審計數據繼續(xù)保留不隨 Firebase 刪除。archived fingerprint 再次出現時進入新 sample epoch累計 count 與 lifetime first-seen 不重置。管理員刪除復用同一 tombstone 窗口并原子刪除對應 D1 分組數據reports、report_daily、report_installations、report_event_dimensions、groups等見beginArchive的 admin 分支。所有狀態(tài)轉換都經由 60 秒租約FIREBASE_GROUP_LEASE_MS串行化防止并發(fā)生命周期操作互相踩踏。回滾只改配置回滾只需設置CRASH_STORAGE_MODEd1并重新部署。回滾時不要刪除outbox、receipt、group-state 或 Firebase 數據。修復 migration/容量/ETag 問題后重新執(zhí)行 dry-run 與--verify-only再切回dual全程 Desktop/CLI 無需升級。隱私與兼容 smoke舊 payload 必須仍然可用舊 payload 可以缺失所有新增字段legacywebview2必須歸一化為webRuntime。同一 engine/kind/reason/exit code 的恢復成功與失敗必須屬于同一 fingerprint。必須逐項驗證原始 install ID 不進入樣本、HTML、應用/審計日志、導出和 pending 文件模塊只保留 basename不包含內容、密鑰、賬號、hostname、完整路徑、GPU 型號和驅動重復事件正確累加 daily/install/event-dimension且早期環(huán)境組合不被覆蓋刪除測試分組會刪除三張診斷聚合表的對應數據診斷事實、ping、metric user 按30 天分塊清理channeltest始終位于 development namespacedev:指紋前綴重復eventId返回202且不重復增加聚合enqueueFirebaseCrash的INSERT OR IGNORE receipts 去重語義Firebase timeout、401、429 或 5xx 會保留 projected outbox交給每 6 小時重試recordFirebaseRetry采用min(24h, 30s × 2^min(attempts,11))指數退避outbox 滿上限 5000 條時返回503客戶端必須保留 pendingDesktop 自動報告按版本和 dedup key 只成功上傳一次失敗不進入 512 條/180 天賬本用戶主動提交的 Desktop/CLI 報告不受本地 fingerprint 去重限制。正常體驗門禁診斷不能讓用戶感知候選版本在殼啟動前只允許一次本地配置讀取、一次非阻塞歸屬鎖和一次小型原子生命周期寫入。Runtime 探測及報告/指標落盤必須在殼啟動后或有界后臺消費者中執(zhí)行COM/GTK 回調只能非阻塞入隊或遞增原子丟棄計數。任何診斷失敗都必須 fail-open——診斷掛了不能拖垮應用。使用同一 SHA 與關閉診斷的基線比較量化門禁如下指標門禁診斷初始化 p95≤ 10 ms診斷初始化 p99≤ 25 msDOM-ready p95 回歸≤max(20 ms, 2%)shutdown p95 回歸≤ 20 ms空閑 CPU 增幅 0.1 個百分點RSS 增幅≤ 2 MiB30 分鐘正常使用期間必須是0 次診斷 reload、0 個輪詢 timer、0 個新增彈窗除已有 ping/metrics 外 0 個額外請求。能力認證矩陣全過程同一候選 SHARuntime、GPU 與驅動信息只記錄在私密實驗表客戶端不采集驅動。矩陣如下平臺必須覆蓋Windows 10 LTSC 201917763VM 實體 GPU系統(tǒng)及最新 Evergreen WebView2GPU 開/關Windows 1019045x64 對照系統(tǒng)及 Evergreen WebView2Windows 11 穩(wěn)定版x64 實機及當前穩(wěn)定 RuntimeWindows arm64正式交叉構建 一臺設備 smokeUbuntu 22.04WebKitGTK 4.0、X11Ubuntu 24.04WebKitGTK 4.1、X11、WaylandDebian 12、Fedora stable、Arch rolling能力 smoke本地會話Intel/AMD/NVIDIA 代表性覆蓋遠程會話Windows RDP 與 Linux remote/xrdp每個環(huán)境執(zhí)行20 次冷啟動/正常退出、10 次更新重啟、60 分鐘工作負載、50 次最小化/恢復以及休眠、顯示器/DPI、遠程連接切換。測試構建可定向終止 renderer/web process驗證只恢復一次。Windows 收集 WER/可靠性監(jiān)視器數據Linux 收集 journal/coredump 元數據。dump/core 僅在用戶明確授權后私密傳輸并在分析后刪除。根因和觀察閉環(huán)沒有證據不結案環(huán)境關聯(lián)證據門檻環(huán)境關聯(lián)至少滿足以下之一兩臺同類實驗節(jié)點復現且對照不復現或三個不同線上安裝命中同一 fingerprint同時該環(huán)境至少有 30 個活躍安裝影響率達到對照 3 倍。GPU workaround 要求每臺 GPU-on 環(huán)境至少2/20復現、兩臺 GPU-off 環(huán)境合計0/40且每臺兩小時長測為 0。workaround 必須按已有能力/Runtime 證據限定不能只按發(fā)行版名稱或 Windows build 拍板。分類處置原則Integrity failure → 轉簽名、注入和安全軟件調查OOM → 轉內存與會話資源調查Runtime 聚集 → 才支持后續(xù)最低版本或升級策略。renderer 恢復成功不算應用崩潰只有 lifecycle abnormal exit 時必須拿到 WER、journal、dump 或 core 之一才能結案。上線后七整日觀察上線后觀察七個完整 UTC 日身份覆蓋率目標 95%低于 90% 不展示精確影響率。每天檢查legacy replay、fatal/recovered/degraded 數量關系、recovery failure、平臺/Runtime/GPU 影響率、D1 增長、retention 和查詢耗時。證據不足就保持 open 并延長至 30 天。只有根因被證實后才發(fā)布定向補丁修復后實驗室要求0/40復現。總結一套可審計、可回滾、證據驅動的診斷發(fā)布范式DeepSeek-Reasonix 的崩潰診斷鏈路把「發(fā)布、隱私、性能、根因」四個環(huán)節(jié)串成了單一閉環(huán)發(fā)布順序保證每個里程碑都有回滾點700 MiB 固定預算讓 Spark 層長期穩(wěn)定隱私 smoke 守住樣本邊界性能門禁確保診斷不可感知能力矩陣覆蓋 Windows/Linux 全平臺組合而根因閉環(huán)則用 fingerprint 影響率與實驗室復現率雙重證據約束補丁發(fā)布。對任何需要自建崩潰上報系統(tǒng)的團隊而言d1 → dual → firebase的影子對比切換、--apply與--verify-only分離的遷移流程、以及「0/40 復現才結案」的紀律都是可以直接復用的工程范式。【免費下載鏈接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.項目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 DeepSeek-Reasonix Desktop 崩潰診斷運行手冊：從 Firebase Spark 發(fā)布到根因閉環(huán)的完整實施指南
DeepSeek-Reasonix Desktop 崩潰診斷運行手冊從 Firebase Spark 發(fā)布到根因閉環(huán)的完整實施指南【免費下載鏈接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.項目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix本手冊面向負責 DeepSeek-Reasonix 桌面端Windows/Linux崩潰診斷鏈路的運維與研發(fā)人員完整覆蓋診斷數據的發(fā)布順序、Spark 容量預算、隱私合規(guī)、性能門禁、跨平臺能力認證矩陣以及根因閉環(huán)判定標準。閱讀本文后你將掌握如何在不依賴 Cloudflare 付費服務的前提下以「D1 → dual → firebase」三段式滾動切換完成崩潰報告的采集、投遞與審計歸檔并能依據明確的指紋fingerprint影響率證據決定何時發(fā)布定向補丁。手冊定位診斷鏈路是一套可發(fā)布、可回滾的工程系統(tǒng)跨平臺 Desktop 診斷鏈路涉及客戶端上報、Cloudflare Workers 接收、D1 聚合存儲與 Firebase Realtime Database 樣本歸檔多個環(huán)節(jié)其發(fā)布、隱私、性能與根因調查必須形成閉環(huán)。本手冊強調兩點前提Windows build17763Windows 10 LTSC 2019是重點實驗環(huán)境而不是代碼白名單——它代表最老、能力最受限的運行時組合用于暴露兼容性問題發(fā)布診斷版本本身不代表問題已經解決。診斷鏈路的每個版本都必須經歷 7 天完整 UTC 日對比、能力矩陣驗收與根因證實之后才允許進入正式 feature release。整套鏈路的核心代碼位于 workers/crash-reportCloudflare Worker與 desktop桌面端 Go 宿主本手冊即圍繞這兩部分的聯(lián)調發(fā)布展開。發(fā)布順序十二步從零搭建到穩(wěn)定觀察1. 隔離的 Firebase Spark 項目Firebase 項目必須保持Spark免費層且不關聯(lián) Cloud Billing只在asia-southeast1區(qū)域創(chuàng)建 Realtime Database并部署 workers/crash-report/firebase/database.rules.json。該規(guī)則文件內容為{ rules: { .read: false, .write: false } }即客戶端對數據庫的讀寫均被拒絕——所有數據寫入只允許通過 Worker 的服務端憑據完成。不得啟用 Functions、Firestore、BigQuery、Hosting、Storage 或 Secret Manager 中任何一項將攻擊面與費用面同時壓到最小。2. 倉庫 Secret 與服務賬號最小授權在倉庫 Actions Secrets 中配置三個 SecretSecret 名稱用途FIREBASE_DATABASE_URLRealtime Database 實例地址FIREBASE_CLIENT_EMAIL專用服務賬號郵箱FIREBASE_PRIVATE_KEY服務賬號私鑰服務賬號必須專用于 crash 投遞且僅授予 Realtime Database 權限不得附帶其他 Google Cloud 權限。嚴禁使用 Web Firebase 配置也不得在 Desktop 產物中攜帶 Firebase SDK 或任何配置——客戶端完全不接觸 Firebase。3. 凍結候選 SHA唯一候選提交 SHA 一經選定即凍結已發(fā)布的 tag 不得移動或重建保證后續(xù)所有構建、遷移與對比基于同一份代碼。4. 備份 D1 并執(zhí)行 diagnostics-v2 遷移先備份 D1再運行npm run migrate:diagnostics-v2該命令由 workers/crash-report/scripts/apply-diagnostics-v2.mjs 實現會在寫入前記錄新的 D1Time Travel bookmark見腳本中對wrangler d1 time-travel info的調用隨后應用 workers/crash-report/migrate-diagnostics-v2.sql。該遷移是純增量additive的reports表新增webview2、web_runtime兩列pings與cli_pings新增os_build、os_revision、channel、distro_id、distro_version、kernel_version、session_type、runtime_engine、runtime_version、gpu_mode等跨平臺歸屬列新建聚合表report_daily、report_installations、report_event_dimensions及配套索引fingerprint/date新建diagnostics_meta元數據表并寫入installation_linked_since鍵。已退休的metric_users和cli_metric_users在 #9379 中退役不再是必需表不得重建。關鍵約束活躍 diagnostics 表出現任何 partial部分缺失狀態(tài)時仍然 fail closed——遷移腳本會在寫入前檢查完整 schema缺一半就拒絕執(zhí)行絕不帶著殘缺結構上線。5. 執(zhí)行 Firebase crash 遷移運行npm run migrate:firebase-crash實現見 workers/crash-report/scripts/apply-firebase-crash.mjs。流程為先記錄 D1 Time Travel bookmark再依次應用第一階段 workers/crash-report/migrate-firebase-crash.sql 與第二階段 workers/crash-report/migrate-firebase-crash-capacity.sql任一階段部分完成時 fail closed腳本用classifyFirebaseCrashSchema將表/索引狀態(tài)歸類為complete/absent/partial遇到partial直接拋錯終止。第一階段創(chuàng)建三類核心結構firebase_crash_outbox投遞隊列state限定queued/processing/projected配套firebase_crash_outbox_retry重試索引firebase_crash_receipts投影回執(zhí)記錄group_count、latest_slot、first_samplefirebase_crash_group_leases舊版租約表僅用于滾動部署兼容新邏輯使用firebase_crash_group_state。遷移前還會執(zhí)行 Spark 容量預檢firebaseCrashCapacityQuery按 groups 表的status與last_seen估算預留字節(jié)超過 700 MiB 直接拒絕。遷移后需驗證 outbox、receipt、兼容 lease 表、firebase_crash_group_state及全部投遞/生命周期索引齊全。6. 驗證診斷聚合對象確認以下對象存在且結構正確report_daily、report_installations、report_event_dimensions、diagnostics_meta、fingerprint/date 索引、ping 窗口索引以及installation_linked_since鍵值。7. GitHub Actions 雙階段部署dry-run 先行在Actions Deploy crash worker Run workflow中選擇main-v2分支并將Firebase crash history operation設為dry-run任務使用現有倉庫 Secret經canaryenvironment 審批不會部署 Worker腳本按每頁 200 個 fingerprint的 keyset 分頁讀取歷史數據PAGE_SIZE 200逐頁評估遷移容量預計預留必須不超過 700 MiB日志只輸出計數、fingerprint 前綴和摘要絕不落原始樣本。確認 dry-run 結果后重新觸發(fā)并將操作設為apply輸入精確確認短語APPLY_FIREBASE_CRASH_DATA任務會在同一 runner 內依次執(zhí)行--apply與--verify-only保證寫入后立即核驗。后續(xù)獨立核驗可單獨選擇verify-only。已認證的運維人員仍可在本機直接運行實現見 workers/crash-report/scripts/migrate-firebase-data.mjsnpm run migrate:firebase-data # 評估模式 npm run migrate:firebase-data -- --apply # 執(zhí)行遷移 npm run migrate:firebase-data -- --verify-only # 只核驗遷移默認 checkpoint 為權限0600且已 gitignore 的.firebase-crash-migration-state.json可用--checkpointpath改路徑只有明確重跑時才使用--reset-checkpoint。腳本內部以服務賬號私鑰簽發(fā) JWTurn:ietf:params:oauth:grant-type:jwt-bearer換取 OAuth token并對每個事件生成確定性的sha256(firebase-migration\nfingerprint\nid)前 32 位作為eventId確保可重復執(zhí)行不產生重復數據。8. Worker 以 dual 模式做 smokeWorker 先使用dual模式部署workers/crash-report/wrangler.toml 中CRASH_STORAGE_MODE d1為安全默認值需顯式改為dual。用舊 Report/Ping/Metrics 報文、legacywebview2、Windows/LinuxwebRuntimepayload 做channeltest的 smoke 測試。channeltest流量始終落入 development namespace——workers/crash-report/src/diagnostics_v2.ts 中developmentGroupSQL groups.fingerprint LIKE dev:%測試指紋以dev:前綴隔離絕不混入 release 崩潰優(yōu)先級index.test.ts中也有keeps development reports out of release crash priority用例保障。9. 七整日影子對比后切換 firebase連續(xù)比較7 個完整 UTC 日fingerprint、計數、樣本和脫敏結果一致后才把CRASH_STORAGE_MODE從dual切換為firebase。Firebase 模式下 D1 只保留聚合、索引和有界 outbox不再寫入新reports原文。模式枚舉定義在 workers/crash-report/src/crash_delivery.tsd1 | dual | firebase非法值直接拋錯。10. 簽名構建與 feature release用同一 SHA 生成簽名 Windows/Linux 構建能力矩陣與性能門禁見下文全部通過后才發(fā)布 feature release。11. 歸檔舊樣本并保留三模式回滾穩(wěn)定觀察 7 天后歸檔 D1 舊原始樣本。保留d1、dual、firebase三種回滾模式Worker 回滾不要求客戶端升級——因為模式只是 Worker 側配置客戶端上報協(xié)議不變。12. 管理界面審計整理通過管理界面整理歷史數據忽略[go panic] safe/v9.9.9等已知噪音將72daba81標記為在desktop-v1.19.3解決忽略舊desktop.abnormal_exitreplay 分組保證審計視圖聚焦真實問題。Spark 容量、生命周期與回滾700 MiB 固定預算Worker 固定執(zhí)行 700 MiB 預留上限workers/crash-report/src/crash_delivery.ts 中FIREBASE_STORAGE_BUDGET_BYTES 700 * 1024 * 1024按樣本狀態(tài)分檔預留樣本狀態(tài)每組預留說明active640 KiB活躍分組全量樣本compacted128 KiB壓縮后的 marker 樣本archiving32 KiB歸檔過渡期archived0已歸檔不占預算達到 80% 時FIREBASE_STORAGE_WARNING_BYTES復用現有 webhook 告警并在后臺提示新組或擴容會越過上限時必須在創(chuàng)建 outbox 前返回503見reserveFirebaseGroup的容量條件。該上限是硬約束不得改為可配置項。生命周期狀態(tài)機只有resolved/ignored分組參與生命周期workers/crash-report/src/firebase_lifecycle.ts 的runFirebaseCrashLifecycle三階段30 天最近 5 個樣本替換為帶 fencing租約代際的 marker保留當前 sample epoch 首個樣本狀態(tài)active → compacted60 天tombstone 全部樣本路徑狀態(tài)compacted → archivingarchiving 滿 24 小時條件刪除 Firebase groupdeleteFirebaseCrashGroupConditional狀態(tài)archiving → archived。D1 側的計數、狀態(tài)、備注、聚合和審計數據繼續(xù)保留不隨 Firebase 刪除。archived fingerprint 再次出現時進入新 sample epoch累計 count 與 lifetime first-seen 不重置。管理員刪除復用同一 tombstone 窗口并原子刪除對應 D1 分組數據reports、report_daily、report_installations、report_event_dimensions、groups等見beginArchive的 admin 分支。所有狀態(tài)轉換都經由 60 秒租約FIREBASE_GROUP_LEASE_MS串行化防止并發(fā)生命周期操作互相踩踏。回滾只改配置回滾只需設置CRASH_STORAGE_MODEd1并重新部署。回滾時不要刪除outbox、receipt、group-state 或 Firebase 數據。修復 migration/容量/ETag 問題后重新執(zhí)行 dry-run 與--verify-only再切回dual全程 Desktop/CLI 無需升級。隱私與兼容 smoke舊 payload 必須仍然可用舊 payload 可以缺失所有新增字段legacywebview2必須歸一化為webRuntime。同一 engine/kind/reason/exit code 的恢復成功與失敗必須屬于同一 fingerprint。必須逐項驗證原始 install ID 不進入樣本、HTML、應用/審計日志、導出和 pending 文件模塊只保留 basename不包含內容、密鑰、賬號、hostname、完整路徑、GPU 型號和驅動重復事件正確累加 daily/install/event-dimension且早期環(huán)境組合不被覆蓋刪除測試分組會刪除三張診斷聚合表的對應數據診斷事實、ping、metric user 按30 天分塊清理channeltest始終位于 development namespacedev:指紋前綴重復eventId返回202且不重復增加聚合enqueueFirebaseCrash的INSERT OR IGNORE receipts 去重語義Firebase timeout、401、429 或 5xx 會保留 projected outbox交給每 6 小時重試recordFirebaseRetry采用min(24h, 30s × 2^min(attempts,11))指數退避outbox 滿上限 5000 條時返回503客戶端必須保留 pendingDesktop 自動報告按版本和 dedup key 只成功上傳一次失敗不進入 512 條/180 天賬本用戶主動提交的 Desktop/CLI 報告不受本地 fingerprint 去重限制。正常體驗門禁診斷不能讓用戶感知候選版本在殼啟動前只允許一次本地配置讀取、一次非阻塞歸屬鎖和一次小型原子生命周期寫入。Runtime 探測及報告/指標落盤必須在殼啟動后或有界后臺消費者中執(zhí)行COM/GTK 回調只能非阻塞入隊或遞增原子丟棄計數。任何診斷失敗都必須 fail-open——診斷掛了不能拖垮應用。使用同一 SHA 與關閉診斷的基線比較量化門禁如下指標門禁診斷初始化 p95≤ 10 ms診斷初始化 p99≤ 25 msDOM-ready p95 回歸≤max(20 ms, 2%)shutdown p95 回歸≤ 20 ms空閑 CPU 增幅 0.1 個百分點RSS 增幅≤ 2 MiB30 分鐘正常使用期間必須是0 次診斷 reload、0 個輪詢 timer、0 個新增彈窗除已有 ping/metrics 外 0 個額外請求。能力認證矩陣全過程同一候選 SHARuntime、GPU 與驅動信息只記錄在私密實驗表客戶端不采集驅動。矩陣如下平臺必須覆蓋Windows 10 LTSC 201917763VM 實體 GPU系統(tǒng)及最新 Evergreen WebView2GPU 開/關Windows 1019045x64 對照系統(tǒng)及 Evergreen WebView2Windows 11 穩(wěn)定版x64 實機及當前穩(wěn)定 RuntimeWindows arm64正式交叉構建 一臺設備 smokeUbuntu 22.04WebKitGTK 4.0、X11Ubuntu 24.04WebKitGTK 4.1、X11、WaylandDebian 12、Fedora stable、Arch rolling能力 smoke本地會話Intel/AMD/NVIDIA 代表性覆蓋遠程會話Windows RDP 與 Linux remote/xrdp每個環(huán)境執(zhí)行20 次冷啟動/正常退出、10 次更新重啟、60 分鐘工作負載、50 次最小化/恢復以及休眠、顯示器/DPI、遠程連接切換。測試構建可定向終止 renderer/web process驗證只恢復一次。Windows 收集 WER/可靠性監(jiān)視器數據Linux 收集 journal/coredump 元數據。dump/core 僅在用戶明確授權后私密傳輸并在分析后刪除。根因和觀察閉環(huán)沒有證據不結案環(huán)境關聯(lián)證據門檻環(huán)境關聯(lián)至少滿足以下之一兩臺同類實驗節(jié)點復現且對照不復現或三個不同線上安裝命中同一 fingerprint同時該環(huán)境至少有 30 個活躍安裝影響率達到對照 3 倍。GPU workaround 要求每臺 GPU-on 環(huán)境至少2/20復現、兩臺 GPU-off 環(huán)境合計0/40且每臺兩小時長測為 0。workaround 必須按已有能力/Runtime 證據限定不能只按發(fā)行版名稱或 Windows build 拍板。分類處置原則Integrity failure → 轉簽名、注入和安全軟件調查OOM → 轉內存與會話資源調查Runtime 聚集 → 才支持后續(xù)最低版本或升級策略。renderer 恢復成功不算應用崩潰只有 lifecycle abnormal exit 時必須拿到 WER、journal、dump 或 core 之一才能結案。上線后七整日觀察上線后觀察七個完整 UTC 日身份覆蓋率目標 95%低于 90% 不展示精確影響率。每天檢查legacy replay、fatal/recovered/degraded 數量關系、recovery failure、平臺/Runtime/GPU 影響率、D1 增長、retention 和查詢耗時。證據不足就保持 open 并延長至 30 天。只有根因被證實后才發(fā)布定向補丁修復后實驗室要求0/40復現。總結一套可審計、可回滾、證據驅動的診斷發(fā)布范式DeepSeek-Reasonix 的崩潰診斷鏈路把「發(fā)布、隱私、性能、根因」四個環(huán)節(jié)串成了單一閉環(huán)發(fā)布順序保證每個里程碑都有回滾點700 MiB 固定預算讓 Spark 層長期穩(wěn)定隱私 smoke 守住樣本邊界性能門禁確保診斷不可感知能力矩陣覆蓋 Windows/Linux 全平臺組合而根因閉環(huán)則用 fingerprint 影響率與實驗室復現率雙重證據約束補丁發(fā)布。對任何需要自建崩潰上報系統(tǒng)的團隊而言d1 → dual → firebase的影子對比切換、--apply與--verify-only分離的遷移流程、以及「0/40 復現才結案」的紀律都是可以直接復用的工程范式。【免費下載鏈接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.項目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考