GitLab

message_delta 应完全覆盖 message_start 的 usage 数据，
而非仅在值为 0 时才更新。

## 问题背景

1. Gemini CLI 没有明确的会话标识（如 Claude Code 的 metadata.user_id）
2. thoughtSignature 与具体上游账号强绑定，跨账号使用会导致 400 错误
3. 粘性会话切换账号或 cache 丢失时，旧签名会导致请求失败

## 解决方案

### 1. Gemini CLI 会话标识提取

- 从 `x-gemini-api-privileged-user-id` header 和请求体中的 tmp 目录哈希生成会话标识
- 组合策略：SHA256(privileged-user-id + ":" + tmp_dir_hash)
- 正则提取：`/\.gemini/tmp/([A-Fa-f0-9]{64})`

### 2. 跨账号 thoughtSignature 清理

实现三种场景的智能清理：

1. **Cache 命中 + 账号切换**
   - 粘性会话绑定的账号与当前选择的账号不同时清理

2. **同一请求内 failover 切换**
   - 通过 sessionBoundAccountID 跟踪，检测重试时的账号切换

3. **Gemini CLI + Cache 未命中 + 含签名**
   - 预防性清理，避免 cache 丢失后首次转发就 400
   - 仅对 Gemini CLI 请求且请求体包含 thoughtSignature 时触发

## 修改内容

### backend/internal/handler/gemini_v1beta_handler.go
- 添加 `extractGeminiCLISessionHash` 函数提取 Gemini CLI 会话标识
- 添加 `isGeminiCLIRequest` 函数识别 Gemini CLI 请求
- 实现账号切换检测与 thoughtSignature 清理逻辑
- 添加 `geminiCLITmpDirRegex` 正则表达式

### backend/internal/service/gateway_service.go
- 添加 `GetCachedSessionAccountID` 方法查询粘性会话绑定的账号 ID

### backend/internal/service/gemini_native_signature_cleaner.go (新增)
- 实现 `CleanGeminiNativeThoughtSignatures` 函数
- 递归清理 JSON 中的所有 thoughtSignature 字段
- 支持任意 JSON 顶层类型（object/array）

### backend/internal/handler/gemini_cli_session_test.go (新增)
- 测试 Gemini CLI 会话哈希提取逻辑
- 测试 tmp 目录正则匹配
- 覆盖有/无 privileged-user-id 的场景

## 影响范围

- 修复 Gemini CLI 多轮对话时账号切换导致的 400 错误
- 提高粘性会话的稳定性和容错能力
- 不影响其他客户端（Claude Code 等）的会话标识生成

## 测试

- 单元测试：go test -tags=unit ./internal/handler -run TestExtractGeminiCLISessionHash
- 单元测试：go test -tags=unit ./internal/handler -run TestGeminiCLITmpDirRegex
- 编译验证：go build ./cmd/server

- Update/BulkUpdate 按不可调度字段触发缓存刷新
- GatewayCache 支持多前缀会话键清理
- 模型路由与混合调度优化粘性会话处理
- 补充调度与缓存相关测试覆盖

- Update/BulkUpdate 按不可调度字段触发缓存刷新
- GatewayCache 支持多前缀会话键清理
- 模型路由与混合调度优化粘性会话处理
- 补充调度与缓存相关测试覆盖

- 新增 session_id_masking_enabled 配置，启用后将在15分钟内固定
  metadata.user_id 中的 session ID
- TLS fingerprint 模块日志从自定义 debugLog 迁移到 slog
- main.go 添加 slog 初始化，根据 gin mode 设置日志级别
- 前端创建/编辑账号模态框添加会话ID伪装开关
- 多语言支持（中英文）

- 新增 GetCurrentWindowStartTime() 方法，当窗口过期时自动使用新的预测窗口开始时间
- UpdateSessionWindow 更新窗口时间后触发 outbox 事件同步调度器缓存
- 统一所有窗口费用查询入口使用新方法

修复 golangci-lint unused 检查报错

- 支持Anthropic OAuth/SetupToken账号的5h窗口费用阈值控制
- 支持账号级别的并发会话数量限制
- 使用Redis缓存窗口费用(30秒TTL)减少数据库压力
- 费用计算基于标准费用(不含账号倍率)

- gateway.scheduling.fallback_selection_mode: "last_used"(默认) 或 "random"
- last_used: 按最后使用时间排序（轮询效果）
- random: 同优先级内随机选择

  支持为分组配置模型路由规则，可以指定特定模型模式优先使用的账号列表。

  - 新增 model_routing 字段存储路由配置（JSONB格式，支持通配符匹配）

  - 新增 model_routing_enabled 字段控制是否启用路由

  - 更新后端 handler/service/repository 支持路由配置的增删改查

  - 更新前端 GroupsView 添加路由配置界面

  - 添加数据库迁移脚本 040/041

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

新增 OpenAI/Claude TokenProvider 与缓存键生成
扩展 OAuth 缓存失效覆盖更多平台
统一 OAuth 缓存前缀与依赖注入

- 新增 accounts.rate_multiplier（默认 1.0，允许 0）
- 使用 usage_logs.account_rate_multiplier 记录倍率快照，避免历史回算
- 统计/导出/管理端展示账号口径费用（total_cost * account_rate_multiplier）

## 问题描述
调度器快照更新存在0.5-1秒的延迟（Outbox轮询间隔），导致在账号被限流或过载后的短时间窗口内，
可能仍会被选中，造成请求失败。

## 根本原因
账号选择逻辑依赖调度器快照（listSchedulableAccounts），但快照更新有延迟：
- Outbox轮询: 每1秒检查一次变更事件
- 全量重建: 每300秒重建一次
- 时间窗口: 账号状态变更后0.5-1秒内，快照可能未更新

## 解决方案
在账号选择循环中添加IsSchedulable()实时检查，作为第二道防线：
1. 第一道防线: 调度器快照过滤（可能有延迟）
2. 第二道防线: IsSchedulable()实时检查（本次修复）

IsSchedulable()会检查：
- RateLimitResetAt: 限流重置时间
- OverloadUntil: 过载持续时间
- TempUnschedulableUntil: 临时不可调度时间
- Status: 账号状态
- Schedulable: 可调度标志

## 修改范围
### OpenAI Gateway Service
- SelectAccountForModelWithExclusions: 添加IsSchedulable()检查
- SelectAccountWithLoadAwareness: 添加IsSchedulable()检查

### Gateway Service (Claude/Gemini/Antigravity)
- 负载感知选择候选账号筛选: 添加IsSchedulable()检查
- selectAccountForModelWithPlatform: 添加IsSchedulable()检查
- selectAccountWithMixedScheduling: 添加IsSchedulable()检查

### 测试用例
- OpenAI: 添加2个测试用例验证限流账号过滤
- Gateway: 添加2个测试用例验证限流和过载账号过滤

### 其他修复
- ops_repo_preagg.go: 修复platform为NULL时的聚合问题

## 测试结果
所有单元测试通过 ✅

此提交解决了思考块 (thinking blocks) 在转发过程中的兼容性问题。

主要变更：

1. **思考块优化 (Thinking Blocks)**：
   - 在 AntigravityGatewayService 中增加了 sanitizeThinkingBlocks 处理，强制移除思考块中不支持的 cache_control 字段（避免 Anthropic/Vertex AI 报错）
   - 实现历史思考块展平 (Flattening)：将非最后一条消息中的思考块转换为普通文本块，以绕过上游对历史思考块签名的严格校验
   - 增加 cleanCacheControlFromGeminiJSON 作为最后一道防线，确保转换后的 Gemini 请求中不残留非法的 cache_control

2. **GatewayService 缓存控制优化**：
   - 更新缓存控制逻辑，跳过 thinking 块（thinking 块不支持 cache_control 字段）
   - 增加 removeCacheControlFromThinkingBlocks 函数强制清理

关联 Issue: #225

- 调度热路径优先读 Redis 快照，保留分组排序语义
- outbox 回放 + 全量重建纠偏，失败重试不推进水位
- 自动 Atlas 基线对齐并同步调度配置示例

- 添加 StreamTimeoutSettings 配置结构体和系统设置
- 实现 TimeoutCounterCache Redis 计数器用于累计超时次数
- 在 RateLimitService 添加 HandleStreamTimeout 方法
- 在 gateway_service、openai_gateway_service、antigravity_gateway_service 中调用超时处理
- 添加后端 API 端点 GET/PUT /admin/settings/stream-timeout
- 添加前端配置界面到系统设置页面
- 支持配置：启用开关、超时阈值、处理方式、暂停时长、触发阈值、阈值窗口

默认配置：
- 启用：true
- 超时阈值：60秒
- 处理方式：临时不可调度
- 暂停时长：5分钟
- 触发阈值：3次
- 阈值窗口：10分钟

**新增功能**:
- 新建ops_upstream_error_events表存储上游服务错误详情
- 支持记录上游429/529/5xx错误的详细上下文信息
- 提供按时间范围查询上游错误事件的API

**后端改动**:
1. 模型层（ops_models.go, ops_port.go）:
   - 新增UpstreamErrorEvent结构体
   - 扩展Repository接口支持上游错误事件CRUD

2. 仓储层（ops_repo.go）:
   - 实现InsertUpstreamErrorEvent写入上游错误
   - 实现GetUpstreamErrorEvents按时间范围查询

3. 服务层（ops_service.go, ops_upstream_context.go）:
   - ops_service: 新增GetUpstreamErrorEvents查询方法
   - ops_upstream_context: 封装上游错误上下文构建逻辑

4. Handler层（ops_error_logger.go）:
   - 新增GetUpstreamErrorsHandler处理上游错误查询请求

5. Gateway层集成:
   - antigravity_gateway_service.go: 429/529错误时记录上游事件
   - gateway_service.go: OpenAI 429/5xx错误时记录
   - gemini_messages_compat_service.go: Gemini 429/5xx错误时记录
   - openai_gateway_service.go: OpenAI 429/5xx错误时记录
   - ratelimit_service.go: 429限流错误时记录

**数据记录字段**:
- request_id: 关联ops_logs主记录
- platform/model: 上游服务标识
- status_code/error_message: 错误详情
- request_headers/response_body: 调试信息（可选）
- created_at: 错误发生时间