Skip to content

chore: reset 判定と束ね待ちのコメントを実装に合わせ、過大側の危険を書く - #5407

Merged
takecchi merged 1 commit into
mainfrom
chore/usage-reset-comment-fixes
Oct 28, 2026
Merged

takecchi merged 1 commit into
mainfrom
chore/usage-reset-comment-fixes

Conversation

@takecchi

Copy link
Copy Markdown
Owner

コメントだけの変更(挙動は変えない)。#5405・#5406 の続き。

  • usage.ts の detectReset の上のコメントを、今の条件(欠落ぶんの前回 cost が今回の全モデルの cost 合計より大きいときだけ reset。小さな欠落は変化なし)に合わせた。
  • 同じコメントに、両向きの危険を書いた。過大に数える側: 数え直しでない読みで opus が丸ごと欠け他のモデルだけが載ると誤って reset になり、基準が今回だけになるので、次の累積で opus が戻ると opus の全量が二重計上される(fix: 累積に載らなかったモデルを数え直しと誤認して台帳へ二重に積む #5402 と同じ規模)。少なく数える側: 欠落が支配的でない数え直しは拾えない。台帳は推定値であること、reset は日誌(turn_usage 行の reset と gauge の exchange)で見張れることも書いた。
  • clone.ts の INBOX_SETTLE_MS のコメントを外部の窓(と合成した報告の窓)の説明に絞り、報告の窓は REPORT_SETTLE_MS と書いた。
  • clone.ts の #pump の待ちの前のコメントを、settleWaitFor の実装に合わせた(報告の窓は合成していない報告以外が届くと切れ、外部の窓は人間起点だけで切れる。Inbox#settle は待ちに入る前に積まれていた割り込みも見る)。

検証: prettier・eslint・tsc・usage/inbox の vitest が通った。

コメントだけで、挙動は変えない。
- usage.ts の detectReset: 「今回に無いモデルは変化なし」を、欠落ぶんが今回の合計より大きいときだけ reset、という今の条件に合わせた。あわせて、過大に数える側(誤 reset で opus が二重計上される)と少なく数える側の両方があること、reset は日誌で見張れることを書いた。
- clone.ts: INBOX_SETTLE_MS のコメントを外部の窓の説明に絞り(報告の窓は REPORT_SETTLE_MS)、#pump の待ちの前のコメントを settleWaitFor の interruptWhen の実装(報告の窓は合成していない報告以外で切れ、外部の窓は人間起点だけ)に合わせた。
@takecchi
takecchi merged commit 52dc037 into main Oct 28, 2026
6 checks passed
@takecchi
takecchi deleted the chore/usage-reset-comment-fixes branch October 28, 2026 09:11
takecchi added a commit that referenced this pull request Oct 28, 2026
Issue #5409 を参照(案 A。#5402・#5406・#5407 の続き)。

## 内容
reset の発生を、日誌を引かずに見張れるようにする。読み取りだけで、書き込みと基準の保存は変えない。
- `UsageAggregate`(`aggregate()` の戻り、`GET /usage` の応答)に、任意の `resets:
[{layer, managerId, resets, lastResetAt?}]` を足した。基準(層 × 担当)ごとの回数と最終時刻。
- 基準が1件でもあるときだけ欄を載せる(無ければ欄ごと無い)。reset の無い基準は回数 0・`lastResetAt`
無し(「数え直しが無い」と「基準が無い」を区別するため)。
- 日付に依らない現在値: `from` / `to` / `site` / `tokenId` では絞らず、`layer` /
`managerId` だけで絞る(基準は日付を持たないため)。並びは層、managerId の順。
- インメモリ / fs / pg の3実装の `aggregate()`
が、同じ関数(`resetRowsOfBaselines`)で作る。pg は `usage_baseline`
を(絞り込み付きで)select。
- `alteroid usage` は、1回以上ある基準だけ 1 行ずつ出す(0 回は出さない。0 回だけ・欄なしなら出力は 1
文字も変わらない)。`--json` は無い現状のまま。
- `apps/daemon/openapi.json` を再生成した(`pnpm -C apps/daemon build`)。

## 既存クライアントへの影響
任意欄の追加だけで、既存の欄は変えていない。欄を知らないクライアントは無視でき、`resets` を読まない CLI
の出力も変わらない。ただし基準が1件でもある台帳の応答には `resets` が載る(pg の「既存の応答を変えない」試験の鍵の一覧に
`resets` を足した)。

## 案 B(`reset` の行へ「欠落ぶんで判定した」印を足す案)は入れない
schema を増やすので、A で足りるかを見てから。

## 試験
- 契約(`verifyUsageResetsContract`)を3実装に当てた: 数え直しの後に回数・最終時刻が読める、基準に reset
が無ければ 0 回で最終時刻なし、layer / managerId で絞れる、日付で絞っても変わらない、該当が無ければ欄ごと無い。
- `GET /usage` の応答(絞り込み・日付に依らない)と、`alteroid usage` の表示(1 回以上だけ・0
回は出さない・導入前と出力が変わらない)。

## 変異の確認
- 基準の列挙(`resetRowsOfBaselines` が空を返す)にすると、契約の3実装(インメモリ・fs・pg)と `GET
/usage` の試験が落ちた。
- CLI の表示(`describeUsageResets` を外す)にすると、CLI の表示の試験 2 本が落ちた。
- どちらも戻して全緑。

## 限界

判定そのものは推定で、誤って数え直しとみなす(過大)も拾えない(過少)もありうる。この口は、回数が増え続けていないかを見張るためのもの。過去分の台帳は補正しない。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant