CodexBar 的 SQLite 成本存储对抗性压测框架 StoreStress崩溃安全、WAL 竞争与语料重建验证【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBarStoreStress 是 CodexBar 仓库中一个独立的 SwiftPM 可执行包位于 Scripts/StoreStress专门针对 SQLite 支撑的CostUsageStore进行对抗性adversarial崩溃、锁竞争、语料库重建、WAL 与文件描述符卫生测试。它刻意独立成包使内部测试访问testable import CodexBarCore永远不会进入正式 CodexBar 构建。阅读本文后你将掌握 StoreStress 的构建与全部 8 个子命令的用法、每个压测模式的真实负载设计与底层验证逻辑以及它背后的CostUsageStore事务/重建/预算机制可直接用于复现 crash-safety 验证或评估扫描性能。一、StoreStress 定位为什么需要一个独立的压测包CostUsageStore是 CodexBar 的单写者持久化核心CostUsageStore.swift 中它是一个 actor拥有唯一的可写 SQLite 连接而应用与 CLI 的独立读取方通过只读连接读取 WAL 快照。这类系统最怕的故障不是读不到而是写到一半进程被杀、两个进程抢写锁、数据库膨胀失控等边角场景。StoreStress 的职责就是用确定性模式把这些边角场景打穿用合成数据模拟真实写入形态文件 upsert、token 快照、usage 行、日聚合而不污染真实 Codex session 目录在已知模式下无限写入并被外部 SIGKILL随后用原生的 SQLitePRAGMA integrity_check验证崩溃后数据库仍然完整且总量符合数学预期对只读连接施加持续读压力并核对数据不变量input output反复开关 store 检查文件描述符泄漏用只读的真实会话语料快照做全量冷重建与增量扫描计时。二、构建与运行独立包、独立目标StoreStress 的包定义见 Scripts/StoreStress/Package.swiftswift-tools-version: 6.2平台要求.macOS(.v14)以相对路径../..依赖根目录的CodexBar包可执行目标依赖CodexBarCore产品。注意它把 Swift 语言模式显式锁定为.v5swiftLanguageMode(.v5)并且排除了Package.swift与README.md自身避免源文件重复。在Scripts/StoreStress目录下构建优化版必须带-enable-testing因为main.swift使用testable import CodexBarCore访问内部 APIswift build -c release -Xswiftc -enable-testing不带参数运行注意--之后的参数才是 StoreStress 自己的参数避免被 SwiftPM 解析swift run -c release -Xswiftc -enable-testing StoreStress --会打印全部可用子命令。约定所有 store/cache 参数都应指向一次性临时目录rebuild与incremental可选接受 sessions root从而可以在只读的真实语料快照上测量而不写入真实的 Codex session 或 CodexBar 缓存目录。2.1 命令行总览main.swift见 Scripts/StoreStress/main.swift的用法为storestress writer|read|crashwriter|vacuumcrasher|verify|rebuild|incremental|fdcycles|holder path [args]各子命令及默认参数如下表子命令参数默认值作用writercacheRoot [seconds]60s合成写入 周期性 retention/vacuumreaddbPath [seconds]60s只读连接持续压测读查询并校验不变量crashwritercacheRoot—确定性模式无限写入由外部 SIGKILLvacuumcrashercacheRoot [marker]无 marker增长 retention budget 循环由外部 SIGKILLverifydbPath [mode]crash原生 integrity_check 崩溃后不变量验证rebuildcacheRoot [passes] [sessionsRoot]12 passes从真实语料全量冷重建incrementalcacheRoot [sessionsRoot]—对未变化语料做单次增量扫描fdcyclescacheRoot [cycles]100 cycles反复开关 store报告 fd 计数holderdbPath [seconds]8s模拟第二个进程持有写锁需要说明的是main.swift开头的注释只枚举了 7 个子命令但switch中实际实现了 9 个含holderREADME 中的不带参数打印可用子命令其实会直接以 usage 错误退出——运行方式以--help式参数缺失的失败提示为准这是该 harness 的已知设计。三、writer合成写入 retention budget 的综合压力runWritermain.swift在指定秒数内持续执行真实的写调用序列每一轮迭代依次store.upsertFile(...)—— upsert 一个文件记录路径形如/synthetic/session-N.jsonl14 天滚动、3 个模型、大小随迭代增长store.appendTokenSnapshots(...)—— 追加 8 条 token 快照store.appendUsageRows(...)—— 追加 4 条 usage 行每条 256 字节 payloadstore.mergeDayAggregates(...)—— 合并 3 个模型的日聚合增量store.replaceFileDayAggregates(...)—— 替换单文件聚合。其中delta辅助函数特意维持每个已提交事务中 input output这一不变量见 main.swift为后续read子命令校验埋下伏笔。周期性维护任务每 200 轮执行一次retainDayWindow(sinceDay:untilDay:)retention 计为retentionRuns每 500 轮执行一次enforceBudgets(maxRows: 25000, maxFileBytes: 256 * 1024 * 1024)预算执行计为budgetRuns这两个数字正好对应CostUsageStore的生产默认值见 CostUsageStoreCodexCache.swift每 10 轮采样一次-wal文件大小跟踪 WAL 峰值。结束时打印iterations/writeErrors/retentionRuns/budgetRuns/storeRebuilds/walPeakBytes/walFinalBytes任一写错误或一次 store 重建即exit(1)。任何一次 rebuild 都是判定失败——因为对健康数据库而言写路径不应触发重建逻辑。四、read只读 WAL 快照压测与不变量校验runReadermain.swift使用裸 SQLitesqlite3_open_v2(..., SQLITE_OPEN_READONLY, ...)打开数据库这正是应用与 CLI 读取方通过独立只读连接读 WAL 快照的模拟。它先等待 writer 建库最长 10 秒每 100ms 探测一次day_aggregates表设置 5000ms busy timeout然后循环执行SELECT day, SUM(input_tokens), SUM(output_tokens), SUM(request_count) FROM day_aggregates GROUP BY day每次查询包在一个BEGIN ... COMMIT事务中并记录从 BEGIN 到 COMMIT 的耗时对每一行校验input_tokens output_tokenswriter 侧维持的不变量在此被反向核对。结束时输出reads/errors/invariantFailures/p50/p95/p99/max毫秒。任何错误或不变量失败都会exit(1)。由于 WAL 模式下读不阻塞写、写不阻塞读这个子命令实测的是真正的并发读体验而不是串行锁等待。五、崩溃安全三件套crashwriter / vacuumcrasher / verify5.1 crashwriter三角数校验runCrashWritermain.swift采用确定性模式第 i 轮向2026-08-01/gpt-crash合并 i 的增量input output。因为mergeDayAggregates的每次调用是一个独立事务若在任意点 SIGKILL已提交的合并次数 k 与累计总量之间必然满足三角数关系total k*(k1)/2。这就是崩溃后数据库要么回到上一个完整提交点、要么完整包含 k 次提交的可验证证据。5.2 vacuumcrasher预算 vacuum 绞肉机runVacuumCrashermain.swift每轮写入 20 个文件、每个文件 16 条 2KB usage 行然后可选地写 marker 文件标记正在执行 retention-vacuum阶段便于外部观察者判断杀死时机retainDayWindow(sinceDay: 2026-08-01, untilDay: 2026-08-02)触发 retentionenforceBudgets(maxRows: 150, maxFileBytes: 2 * 1024 * 1024)—— 这个极紧的预算会迫使deleteOldestRetainedFile、PRAGMA incremental_vacuum(1000000)与PRAGMA wal_checkpoint(TRUNCATE)持续运转见 CostUsageStoreRetention.swift制造删除-回收-检查点在崩溃窗口内反复交叉的恶劣条件。5.3 verify绕过重建逻辑的原生完整性验证runVerifymain.swift刻意只使用裸 SQLiteSQLITE_OPEN_READWRITE避免调用CostUsageStore的出错即重建路径从而让验证结果反映数据库文件本身PRAGMA integrity_check必须返回okcrash模式下对gpt-crash模型执行SUM(input_tokens)、SUM(output_tokens)、SUM(request_count)校验input output k*(k1)/2其中k request_count即确认崩溃点之后没有产生部分提交同时统计files表行数。最终打印integrity/files/committedMerges/total/expected/patternOK与verdictOK|CORRUPT并以退出码区分0 通过1 失败。这验证的正是CostUsageStore.beginSaveTransaction的all-or-nothing承诺单次BEGIN IMMEDIATE覆盖整个 save 周期崩溃中途时磁盘上保持上一完整状态见 CostUsageStore.swift。六、rebuild / incremental只读语料上的扫描性能验证runRebuildmain.swift与runIncrementalmain.swift通过CostUsageScanner.OptionscodexSessionsRoot、cacheRoot、codexScanWorkRecorderForTesting构造扫描器并将refreshMinIntervalSeconds置为 0 以禁用节流生产默认 60 秒见 CostUsageScanner.swift。扫描窗口固定为今天往前 420 天。rebuild的核心是反复调用CostUsageScanner.loadDailyReport(provider: .codex, since:until:options:)直到!catchUpPending processedBytes totalBytes totalBytes 0或达到maxPasses默认 12。每一轮会调用store.syncLoadCodexCache读取codexScanProcessedBytes / codexScanTotalBytes / codexScanCatchUpPending元数据定义于 CostUsageCacheModels.swift并通过CodexScanWorkRecorder的快照统计usageRowsProcessed / usageRowsRepriced最后输出单轮耗时与累计总耗时PASS n wall...s。incremental只做一轮并在输出中额外打印totalTokens。两者的设计目的是一致的把真实 Codex 会话目录作为只读输入量化冷重建多轮收敛与增量扫描的墙钟时间与处理字节量全程不触碰真实缓存目录。七、fdcycles 与 holder描述符卫生与写锁竞争runFDCyclesmain.swift通过FileManager.contentsOfDirectory(atPath: /dev/fd).count统计打开描述符数先建立 baseline然后反复openAndCloseStore构造CostUsageStore并读取一次configuration()记录峰值最后断言final baseline否则exit(1)。这是对连接生命周期管理的回归测试——任何泄漏都会破坏反复开关 store 不涨 fd这一健康属性。runHoldermain.swift模拟第二个 CodexBar 进程正在保存以BEGIN IMMEDIATE获取写锁、写入一条meta记录、睡眠指定秒数默认 8s再 COMMIT。结合writer子命令同时运行即可验证CostUsageStore在 busy timeout默认 5000ms见 CostUsageStore.swift内的锁竞争表现以及shouldRebuild对SQLITE_BUSY / SQLITE_LOCKED等瞬态错误的不重建、保留数据库分类见 CostUsageStore.swift。八、底层机制支撑事务、重建与预算理解结果的钥匙要正确解读上述子命令的成败需要理解CostUsageStore的四个关键机制1. 单写者串行执行器。actor 使用进程级共享的StoreSerialExecutorcom.steipete.codexbar.cost-usage-store队列见 CostUsageStore.swift保证所有可写连接在同一队列上串行化匹配扫描管线的单写者契约。2. all-or-nothing save 事务。beginSaveTransaction以单个BEGIN IMMEDIATE开启事务周期内所有嵌套withDatabase调用加入该事务首个失败会中止整轮写入endSaveTransaction据此 COMMIT 或 ROLLBACKCostUsageStore.swift。这就是crashwriter/vacuumcrasher崩溃安全验证所依赖的语义。3. 条件重建策略。shouldRebuild只对损坏或 schema 漂移类错误重建删除-wal/-shm后重开对SQLITE_BUSY、SQLITE_LOCKED、SQLITE_NOMEM、SQLITE_FULL等瞬态错误一律保留数据库CostUsageStore.swift。因此writer出现storeRebuilds 0即判失败是对该策略的间接验证。4. 预算与回收。enforceBudgets的行预算默认 25000 行与字节预算默认 256 MiB只删除请求窗口之外的文件且优先保护有 buffered lines 或仍被 fork 子代引用的文件触发删除后会重建day_aggregates并标记catchUpPending随后reclaimFreePages执行incremental_vacuumwal_checkpoint(TRUNCATE)见 CostUsageStoreRetention.swift。vacuumcrasher正是让这套逻辑在崩溃窗口内高频运转的绞肉机。此外StoreStress 中所有写调用upsertFile、appendTokenSnapshots、appendUsageRows、mergeDayAggregates、replaceFileDayAggregates的 SQL 形态都可在 CostUsageStoreWrites.swift 中逐一对照例如mergeDayAggregates使用INSERT ... ON CONFLICT(day, model) DO UPDATE SET ... excluded的原子累加upsertFile以path为唯一键做全字段覆盖。数据库 schemameta、files、token_snapshots、usage_rows、file_day_aggregates、day_aggregates、fork_lineage、buffered_lines、discovery_state、lookback_state、accumulators共 11 张表定义于 CostUsageStore.swift与压测中的读写路径一一对应。九、典型验证流程一次完整的崩溃安全演练综合以上子命令一次完整的 crash-safety 演练可以组织为# 1. 启动确定性写入进程单独终端记录 PID swift run -c release -Xswiftc -enable-testing StoreStress crashwriter /tmp/stress-crash # 2. 随机时刻 SIGKILL 写入进程 kill -9 crashwriter-pid # 3. 对被杀后的数据库执行原生完整性 三角数校验 swift run -c release -Xswiftc -enable-testing StoreStress verify /tmp/stress-crash/cost-usage/cost-usage.sqlite crash # 期望输出VERIFY integrityok ... verdictOK退出码 0 # 4. 对 vacuumcrasher 用 marker 文件辅助定位杀死时机 swift run -c release -Xswiftc -enable-testing StoreStress vacuumcrasher /tmp/stress-vac /tmp/stress-vac.marker # 在 marker 存在时 SIGKILL随后同样 verify需要注意的是crashwriter/vacuumcrasher不会自行退出必须由外部进程在验证点杀死verify的数据库路径默认位于cacheRoot/cost-usage/cost-usage.sqliteCostUsageStore会在 cacheRoot 下追加cost-usage/子目录与cost-usage.sqlite文件名见 CostUsageStore.swift。所有压测均应指向一次性临时目录避免污染真实缓存。十、与仓库测试体系的配合StoreStress 与仓库的测试设施互为印证CostUsageStoreCrashHarnessCostUsageStoreCrashHarness.swift提供了供CodexBarCostStoreCrashProbe可执行程序驱动的种子/更新 fixture其saveCycleCheckpointForTesting钩子在保存事务内持久化到第 N 个文件后对自身进程SIGKILLCostUsageStore.swift 中的测试注入点从而在单进程内复现确定性的中断保存点扫描侧CodexScanWorkRecorder则被rebuild/incremental用于统计每轮实际处理的 usage 行。这两套机制一外一内共同构成崩溃注入—重建恢复—完整性验证的闭环是评估CostUsageStore生产可用性的核心手段。从源码结构看StoreStress 被定位为 review/store-stress 验证运行的专用工具main.swift 注释明确Not shipped因此它既不参与 CodexBar 主目标编译也不建议在正常开发流程之外随意运行——它的价值在于当你需要回答这个 SQLite 存储到底经不经得起崩溃与高压时提供一个可复现、可断言的答案。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CodexBar 的 SQLite 成本存储对抗性压测框架 StoreStress：崩溃安全、WAL 竞争与语料重建验证
CodexBar 的 SQLite 成本存储对抗性压测框架 StoreStress崩溃安全、WAL 竞争与语料重建验证【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBarStoreStress 是 CodexBar 仓库中一个独立的 SwiftPM 可执行包位于 Scripts/StoreStress专门针对 SQLite 支撑的CostUsageStore进行对抗性adversarial崩溃、锁竞争、语料库重建、WAL 与文件描述符卫生测试。它刻意独立成包使内部测试访问testable import CodexBarCore永远不会进入正式 CodexBar 构建。阅读本文后你将掌握 StoreStress 的构建与全部 8 个子命令的用法、每个压测模式的真实负载设计与底层验证逻辑以及它背后的CostUsageStore事务/重建/预算机制可直接用于复现 crash-safety 验证或评估扫描性能。一、StoreStress 定位为什么需要一个独立的压测包CostUsageStore是 CodexBar 的单写者持久化核心CostUsageStore.swift 中它是一个 actor拥有唯一的可写 SQLite 连接而应用与 CLI 的独立读取方通过只读连接读取 WAL 快照。这类系统最怕的故障不是读不到而是写到一半进程被杀、两个进程抢写锁、数据库膨胀失控等边角场景。StoreStress 的职责就是用确定性模式把这些边角场景打穿用合成数据模拟真实写入形态文件 upsert、token 快照、usage 行、日聚合而不污染真实 Codex session 目录在已知模式下无限写入并被外部 SIGKILL随后用原生的 SQLitePRAGMA integrity_check验证崩溃后数据库仍然完整且总量符合数学预期对只读连接施加持续读压力并核对数据不变量input output反复开关 store 检查文件描述符泄漏用只读的真实会话语料快照做全量冷重建与增量扫描计时。二、构建与运行独立包、独立目标StoreStress 的包定义见 Scripts/StoreStress/Package.swiftswift-tools-version: 6.2平台要求.macOS(.v14)以相对路径../..依赖根目录的CodexBar包可执行目标依赖CodexBarCore产品。注意它把 Swift 语言模式显式锁定为.v5swiftLanguageMode(.v5)并且排除了Package.swift与README.md自身避免源文件重复。在Scripts/StoreStress目录下构建优化版必须带-enable-testing因为main.swift使用testable import CodexBarCore访问内部 APIswift build -c release -Xswiftc -enable-testing不带参数运行注意--之后的参数才是 StoreStress 自己的参数避免被 SwiftPM 解析swift run -c release -Xswiftc -enable-testing StoreStress --会打印全部可用子命令。约定所有 store/cache 参数都应指向一次性临时目录rebuild与incremental可选接受 sessions root从而可以在只读的真实语料快照上测量而不写入真实的 Codex session 或 CodexBar 缓存目录。2.1 命令行总览main.swift见 Scripts/StoreStress/main.swift的用法为storestress writer|read|crashwriter|vacuumcrasher|verify|rebuild|incremental|fdcycles|holder path [args]各子命令及默认参数如下表子命令参数默认值作用writercacheRoot [seconds]60s合成写入 周期性 retention/vacuumreaddbPath [seconds]60s只读连接持续压测读查询并校验不变量crashwritercacheRoot—确定性模式无限写入由外部 SIGKILLvacuumcrashercacheRoot [marker]无 marker增长 retention budget 循环由外部 SIGKILLverifydbPath [mode]crash原生 integrity_check 崩溃后不变量验证rebuildcacheRoot [passes] [sessionsRoot]12 passes从真实语料全量冷重建incrementalcacheRoot [sessionsRoot]—对未变化语料做单次增量扫描fdcyclescacheRoot [cycles]100 cycles反复开关 store报告 fd 计数holderdbPath [seconds]8s模拟第二个进程持有写锁需要说明的是main.swift开头的注释只枚举了 7 个子命令但switch中实际实现了 9 个含holderREADME 中的不带参数打印可用子命令其实会直接以 usage 错误退出——运行方式以--help式参数缺失的失败提示为准这是该 harness 的已知设计。三、writer合成写入 retention budget 的综合压力runWritermain.swift在指定秒数内持续执行真实的写调用序列每一轮迭代依次store.upsertFile(...)—— upsert 一个文件记录路径形如/synthetic/session-N.jsonl14 天滚动、3 个模型、大小随迭代增长store.appendTokenSnapshots(...)—— 追加 8 条 token 快照store.appendUsageRows(...)—— 追加 4 条 usage 行每条 256 字节 payloadstore.mergeDayAggregates(...)—— 合并 3 个模型的日聚合增量store.replaceFileDayAggregates(...)—— 替换单文件聚合。其中delta辅助函数特意维持每个已提交事务中 input output这一不变量见 main.swift为后续read子命令校验埋下伏笔。周期性维护任务每 200 轮执行一次retainDayWindow(sinceDay:untilDay:)retention 计为retentionRuns每 500 轮执行一次enforceBudgets(maxRows: 25000, maxFileBytes: 256 * 1024 * 1024)预算执行计为budgetRuns这两个数字正好对应CostUsageStore的生产默认值见 CostUsageStoreCodexCache.swift每 10 轮采样一次-wal文件大小跟踪 WAL 峰值。结束时打印iterations/writeErrors/retentionRuns/budgetRuns/storeRebuilds/walPeakBytes/walFinalBytes任一写错误或一次 store 重建即exit(1)。任何一次 rebuild 都是判定失败——因为对健康数据库而言写路径不应触发重建逻辑。四、read只读 WAL 快照压测与不变量校验runReadermain.swift使用裸 SQLitesqlite3_open_v2(..., SQLITE_OPEN_READONLY, ...)打开数据库这正是应用与 CLI 读取方通过独立只读连接读 WAL 快照的模拟。它先等待 writer 建库最长 10 秒每 100ms 探测一次day_aggregates表设置 5000ms busy timeout然后循环执行SELECT day, SUM(input_tokens), SUM(output_tokens), SUM(request_count) FROM day_aggregates GROUP BY day每次查询包在一个BEGIN ... COMMIT事务中并记录从 BEGIN 到 COMMIT 的耗时对每一行校验input_tokens output_tokenswriter 侧维持的不变量在此被反向核对。结束时输出reads/errors/invariantFailures/p50/p95/p99/max毫秒。任何错误或不变量失败都会exit(1)。由于 WAL 模式下读不阻塞写、写不阻塞读这个子命令实测的是真正的并发读体验而不是串行锁等待。五、崩溃安全三件套crashwriter / vacuumcrasher / verify5.1 crashwriter三角数校验runCrashWritermain.swift采用确定性模式第 i 轮向2026-08-01/gpt-crash合并 i 的增量input output。因为mergeDayAggregates的每次调用是一个独立事务若在任意点 SIGKILL已提交的合并次数 k 与累计总量之间必然满足三角数关系total k*(k1)/2。这就是崩溃后数据库要么回到上一个完整提交点、要么完整包含 k 次提交的可验证证据。5.2 vacuumcrasher预算 vacuum 绞肉机runVacuumCrashermain.swift每轮写入 20 个文件、每个文件 16 条 2KB usage 行然后可选地写 marker 文件标记正在执行 retention-vacuum阶段便于外部观察者判断杀死时机retainDayWindow(sinceDay: 2026-08-01, untilDay: 2026-08-02)触发 retentionenforceBudgets(maxRows: 150, maxFileBytes: 2 * 1024 * 1024)—— 这个极紧的预算会迫使deleteOldestRetainedFile、PRAGMA incremental_vacuum(1000000)与PRAGMA wal_checkpoint(TRUNCATE)持续运转见 CostUsageStoreRetention.swift制造删除-回收-检查点在崩溃窗口内反复交叉的恶劣条件。5.3 verify绕过重建逻辑的原生完整性验证runVerifymain.swift刻意只使用裸 SQLiteSQLITE_OPEN_READWRITE避免调用CostUsageStore的出错即重建路径从而让验证结果反映数据库文件本身PRAGMA integrity_check必须返回okcrash模式下对gpt-crash模型执行SUM(input_tokens)、SUM(output_tokens)、SUM(request_count)校验input output k*(k1)/2其中k request_count即确认崩溃点之后没有产生部分提交同时统计files表行数。最终打印integrity/files/committedMerges/total/expected/patternOK与verdictOK|CORRUPT并以退出码区分0 通过1 失败。这验证的正是CostUsageStore.beginSaveTransaction的all-or-nothing承诺单次BEGIN IMMEDIATE覆盖整个 save 周期崩溃中途时磁盘上保持上一完整状态见 CostUsageStore.swift。六、rebuild / incremental只读语料上的扫描性能验证runRebuildmain.swift与runIncrementalmain.swift通过CostUsageScanner.OptionscodexSessionsRoot、cacheRoot、codexScanWorkRecorderForTesting构造扫描器并将refreshMinIntervalSeconds置为 0 以禁用节流生产默认 60 秒见 CostUsageScanner.swift。扫描窗口固定为今天往前 420 天。rebuild的核心是反复调用CostUsageScanner.loadDailyReport(provider: .codex, since:until:options:)直到!catchUpPending processedBytes totalBytes totalBytes 0或达到maxPasses默认 12。每一轮会调用store.syncLoadCodexCache读取codexScanProcessedBytes / codexScanTotalBytes / codexScanCatchUpPending元数据定义于 CostUsageCacheModels.swift并通过CodexScanWorkRecorder的快照统计usageRowsProcessed / usageRowsRepriced最后输出单轮耗时与累计总耗时PASS n wall...s。incremental只做一轮并在输出中额外打印totalTokens。两者的设计目的是一致的把真实 Codex 会话目录作为只读输入量化冷重建多轮收敛与增量扫描的墙钟时间与处理字节量全程不触碰真实缓存目录。七、fdcycles 与 holder描述符卫生与写锁竞争runFDCyclesmain.swift通过FileManager.contentsOfDirectory(atPath: /dev/fd).count统计打开描述符数先建立 baseline然后反复openAndCloseStore构造CostUsageStore并读取一次configuration()记录峰值最后断言final baseline否则exit(1)。这是对连接生命周期管理的回归测试——任何泄漏都会破坏反复开关 store 不涨 fd这一健康属性。runHoldermain.swift模拟第二个 CodexBar 进程正在保存以BEGIN IMMEDIATE获取写锁、写入一条meta记录、睡眠指定秒数默认 8s再 COMMIT。结合writer子命令同时运行即可验证CostUsageStore在 busy timeout默认 5000ms见 CostUsageStore.swift内的锁竞争表现以及shouldRebuild对SQLITE_BUSY / SQLITE_LOCKED等瞬态错误的不重建、保留数据库分类见 CostUsageStore.swift。八、底层机制支撑事务、重建与预算理解结果的钥匙要正确解读上述子命令的成败需要理解CostUsageStore的四个关键机制1. 单写者串行执行器。actor 使用进程级共享的StoreSerialExecutorcom.steipete.codexbar.cost-usage-store队列见 CostUsageStore.swift保证所有可写连接在同一队列上串行化匹配扫描管线的单写者契约。2. all-or-nothing save 事务。beginSaveTransaction以单个BEGIN IMMEDIATE开启事务周期内所有嵌套withDatabase调用加入该事务首个失败会中止整轮写入endSaveTransaction据此 COMMIT 或 ROLLBACKCostUsageStore.swift。这就是crashwriter/vacuumcrasher崩溃安全验证所依赖的语义。3. 条件重建策略。shouldRebuild只对损坏或 schema 漂移类错误重建删除-wal/-shm后重开对SQLITE_BUSY、SQLITE_LOCKED、SQLITE_NOMEM、SQLITE_FULL等瞬态错误一律保留数据库CostUsageStore.swift。因此writer出现storeRebuilds 0即判失败是对该策略的间接验证。4. 预算与回收。enforceBudgets的行预算默认 25000 行与字节预算默认 256 MiB只删除请求窗口之外的文件且优先保护有 buffered lines 或仍被 fork 子代引用的文件触发删除后会重建day_aggregates并标记catchUpPending随后reclaimFreePages执行incremental_vacuumwal_checkpoint(TRUNCATE)见 CostUsageStoreRetention.swift。vacuumcrasher正是让这套逻辑在崩溃窗口内高频运转的绞肉机。此外StoreStress 中所有写调用upsertFile、appendTokenSnapshots、appendUsageRows、mergeDayAggregates、replaceFileDayAggregates的 SQL 形态都可在 CostUsageStoreWrites.swift 中逐一对照例如mergeDayAggregates使用INSERT ... ON CONFLICT(day, model) DO UPDATE SET ... excluded的原子累加upsertFile以path为唯一键做全字段覆盖。数据库 schemameta、files、token_snapshots、usage_rows、file_day_aggregates、day_aggregates、fork_lineage、buffered_lines、discovery_state、lookback_state、accumulators共 11 张表定义于 CostUsageStore.swift与压测中的读写路径一一对应。九、典型验证流程一次完整的崩溃安全演练综合以上子命令一次完整的 crash-safety 演练可以组织为# 1. 启动确定性写入进程单独终端记录 PID swift run -c release -Xswiftc -enable-testing StoreStress crashwriter /tmp/stress-crash # 2. 随机时刻 SIGKILL 写入进程 kill -9 crashwriter-pid # 3. 对被杀后的数据库执行原生完整性 三角数校验 swift run -c release -Xswiftc -enable-testing StoreStress verify /tmp/stress-crash/cost-usage/cost-usage.sqlite crash # 期望输出VERIFY integrityok ... verdictOK退出码 0 # 4. 对 vacuumcrasher 用 marker 文件辅助定位杀死时机 swift run -c release -Xswiftc -enable-testing StoreStress vacuumcrasher /tmp/stress-vac /tmp/stress-vac.marker # 在 marker 存在时 SIGKILL随后同样 verify需要注意的是crashwriter/vacuumcrasher不会自行退出必须由外部进程在验证点杀死verify的数据库路径默认位于cacheRoot/cost-usage/cost-usage.sqliteCostUsageStore会在 cacheRoot 下追加cost-usage/子目录与cost-usage.sqlite文件名见 CostUsageStore.swift。所有压测均应指向一次性临时目录避免污染真实缓存。十、与仓库测试体系的配合StoreStress 与仓库的测试设施互为印证CostUsageStoreCrashHarnessCostUsageStoreCrashHarness.swift提供了供CodexBarCostStoreCrashProbe可执行程序驱动的种子/更新 fixture其saveCycleCheckpointForTesting钩子在保存事务内持久化到第 N 个文件后对自身进程SIGKILLCostUsageStore.swift 中的测试注入点从而在单进程内复现确定性的中断保存点扫描侧CodexScanWorkRecorder则被rebuild/incremental用于统计每轮实际处理的 usage 行。这两套机制一外一内共同构成崩溃注入—重建恢复—完整性验证的闭环是评估CostUsageStore生产可用性的核心手段。从源码结构看StoreStress 被定位为 review/store-stress 验证运行的专用工具main.swift 注释明确Not shipped因此它既不参与 CodexBar 主目标编译也不建议在正常开发流程之外随意运行——它的价值在于当你需要回答这个 SQLite 存储到底经不经得起崩溃与高压时提供一个可复现、可断言的答案。【免费下载链接】CodexBarShow usage stats for OpenAI Codex and Claude Code, without having to login.项目地址: https://gitcode.com/GitHub_Trending/co/CodexBar创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考