generic-issue-log-analysis

name	generic-issue-log-analysis
description	分析当前仓库或用户明确指定的公开 GitHub issue（完整 URL 或 `#1234`）。优先读取 issue 正文和评论，按需下载日志包、截图、配置导出和崩溃转储，建立时间线后结合仓库代码、文档和必要的上游依赖判断根因，并给出修复建议或下一步排查建议。

Generic Issue Log Analysis

Scope

• 默认把 #1234 视为当前仓库 issue。
• 如果用户给了完整 issue URL，则以该 URL 为准。
• 只分析可以直接访问的公开 issue、评论、截图和附件。
• 如果缺少日志、现场图、配置导出或崩溃信息，要先明确说明证据不足，再基于现有材料给出初步判断。
• 如果问题依赖私有环境、外部服务或用户本地状态，而仓库内证据不足，要明确列出还缺哪些材料。

Workflow

1. 规范化输入。

   • #1234 视为当前仓库 issue。
   • 完整 issue URL 以 URL 为准。
   • 如果用户给的是模糊描述，先在 issue 文本里定位编号、链接或关键上下文。

2. 获取 issue 内容。

   • 读取正文和评论。
   • 提取这些信息：版本、分支、平台、环境、任务或入口、预期行为、实际行为、复现步骤、维护者评论、附件链接。
   • 如果维护者、机器人或其他评论已经给出结论，不要直接照抄；仍要用日志、代码和文档自行验证。

3. 提取附件和现场证据。

   • 优先关注日志包、截图、配置导出、崩溃转储、诊断报告和资源导出。
   • 不要假定附件命名固定；除了项目约定命名，也要留意 log、report、debug、crash、dump、config、trace、screenshot 等常见关键词。
   • 如果同一个 issue 有多份日志，先看最新一次复现；如果 issue 在对比不同版本、不同环境或不同控制器，再补看旧样本。

4. 下载并解压附件。

   • 二进制附件不要只靠网页抓取工具直接分析，应先下载到工作区临时目录，例如 .temp/.trash/issue-logs/issue-<number>/。
   • 解压后先列目录，不要假定内部结构固定。
   • 只读取和结论直接相关的文件，不要把整份大日志、整份配置或整个转储内容直接塞进回复。

5. 建立时间线。

   • 先从 issue 文本确定“用户认为出问题的时刻”和复现条件。
   • 再把界面日志、服务日志、运行时日志、截图、配置快照和崩溃信息串成一条时间线。
   • 优先锁定这次复现对应的 task_id、session_id、请求 ID、时间戳或其他稳定标识，再追踪细节。

6. 回溯到代码和文档。

   • 先看本仓库文档、配置定义和实现代码。
   • 如果问题明显落在上游依赖、共享组件、绑定层或外部工具，再按需查看相关仓库或文档。
   • 只看真正相关的模块，不要为了“完整”而把整个依赖栈都扫一遍。

7. 区分 issue 当时环境和当前分支。

   • 先以 issue 文本、附件、部署清单、环境变量快照和缓存状态还原用户当时的实际环境。
   • 再对照当前仓库代码，判断问题是当前仍存在，还是当时存在但现在可能已修复。
   • 如果 issue 很旧，或 PostgreSQL/MySQL schema、API schema、Redis 策略或 Ingress 拓扑与当前主线明显不一致，必要时按对应 tag、release 或历史提交复核旧逻辑。
   • 输出给用户时，接口、环境变量、数据库字段和错误码必须以 API 合约、migration 或实际响应为准；不要把 Rust 内部类型名、SQL 列名或 Redis key 误当作对外接口。

8. 输出结论。

9. 输出结论。

   • 明确区分“已证实的根因”“高概率怀疑点”“证据不足的待确认项”。
   • 给出能执行的下一步，例如修复方向、需要补充的材料、临时绕过方案、是否建议升级或回滚。

Artifact Map

HTTP / API Access Logs

• 模块归属：Ingress、负载均衡器、HTTP middleware、API handler。
• 最适合看：请求方法、路径、状态码、CORS 预检、x-request-id、延迟和来源地址。
• 先用请求 ID、时间戳或稳定客户端哈希把同一次请求跨层关联起来。

Application Logs

• 模块归属：Rust 服务、业务合约、数据库/Redis 适配。
• 最适合看：启动、migration、校验失败、限流、依赖降级、错误链路和优雅退出。
• 不得把完整连接 URL、Secret 或原始遥测内容复制到结论中。

PostgreSQL / MySQL Evidence

• 模块归属：PostgreSQL/MySQL schema migration、事务、唯一约束和持久化真相层。
• 最适合看：driver、migration 版本、约束冲突、锁等待、连接耗尽、查询错误和数据是否真正写入。

Redis Evidence

• 模块归属：跨 Pod 限流、短期协调和缓存。
• 最适合看：连接失败、命令错误、TTL、限流计数和降级行为。
• Redis 证据不能单独证明业务数据已可靠持久化；应回到当前部署使用的 PostgreSQL 或 MySQL 验证。

Kubernetes / Ingress Evidence

• 模块归属：Deployment、Pod、Service、Ingress、DNS、TLS 和 NetworkPolicy。
• 最适合看：就绪/存活探针、滚动升级、重启、端点分布、代理头、证书与流量是否到达 Pod。

Config Snapshots

• 模块归属：环境变量、ConfigMap、Secret 引用、Helm/Kustomize 参数和发布记录。
• 最适合看：实际生效的非敏感配置、镜像版本、端口、依赖地址是否指向预期环境。

Dumps / Crash Reports / Metrics

• 模块归属：崩溃现场、panic、OpenTelemetry/Prometheus 指标与诊断报告。
• 最适合看：异常退出、资源耗尽、吞吐、错误率、请求延迟和跨 Pod 不一致。

How To Filter Evidence

1. 先从 issue 文本拿到这些锚点：

   • 版本、分支、镜像 tag、提交、发布日期
   • 集群、命名空间、节点、Ingress Controller、数据库/Redis 版本
   • API 路径、请求 ID、触发方式、环境变量与复现时间窗口

2. 再从日志和指标里找高价值信号：

   • error、warn、panic、timeout、retry、connection refused
   • request_id、trace ID、Pod 名称、migration 版本、SQLSTATE、Redis key 前缀
   • readiness 失败、Pod 重启、5xx、429、CORS 和 TLS 错误

3. 先锁定“这一次复现”再下钻。

   • 一个日志流通常混有多个 Pod、多个版本和历史重试。
   • 如果 issue 文字说失败，但同一请求 ID 的最终请求成功，要明确写出“本次证据未复现用户描述的问题”。

4. 区分表象和根因。

   • HTTP 状态码、浏览器报错或告警规则经常只是表象。
   • 如果数据库、Redis、Ingress 或应用日志已经给出更直接的错误链路，应优先以最接近根因的证据为准，再解释上层现象。

Common Patterns

• 维护者评论已经给出判断，但日志和代码证据并不支持：

  • 以可验证证据为准，把维护者评论当成补强而不是唯一依据。

• issue 文本说“失败 / 卡死 / 误点”，但对应复现日志最终成功：

  • 先明确“本次日志没有复现出用户描述的问题”。
  • 再区分是用户补错了日志，还是代码里确实存在脆弱点但这次没触发。

• 用户日志里的流程与当前主线代码明显不一致：

  • 先确认 issue 当时的版本、tag 或 release。
  • 不要用当前主线直接否定旧版本问题。

• 配置快照和实际运行日志不一致：

  • 不要立刻认定是用户表述错误。
  • 先确认配置是否在复现后又被修改、是否有多个配置文件、是否存在缓存或导出时机差异。

• 日志显示现场图、诊断包或转储已保存，但附件里没有对应文件：

  • 把“缺失的关键证据”单独写出来。
  • 不要假装已经验证过那部分现场。

• 多层架构项目里某一层日志只暴露表象：

  • 先在最接近问题根因的那层日志定性，再回到上层解释用户看到的现象。

• 证据更接近“场景不支持”而不是“实现缺陷”：

  • 必须给出代码、配置白名单、文档限制或运行时分支依据，而不是只给主观判断。

Correlating With Code

• 先看 issue 模板、README、API 合约、migration、部署清单和运行手册。
• 再看 HTTP 入口、配置定义、业务合约、数据库/Redis 适配与健康检查实现。
• 只有当证据已经明显指向上游 crate、托管数据库、Ingress Controller 或云服务时，才继续看外部仓库或官方文档。

API 与领域名称

• 总结 API、字段、环境变量、错误码、探针或部署资源时，优先使用仓库 API 合约、Rust 类型、migration 和 Kubernetes 清单中已经存在的名称。
• 用户以中文描述概念时，先用原始中文检索文档和代码，再补充已存在的 Rust 标识符或对外 API 名称；不得自行翻译后假定名称。
• 如果日志带有用户自定义名称或 hash，输出时优先保留其脱敏形式；不得反向推断或展示原始身份信息。

Linking Code Evidence

• 如果要指向具体代码行，不要写本地路径加行号，也不要写绝对路径。
• 统一给出对应仓库的远端 GitHub blob 行号链接。
• 链接格式：
  • https://github.com/<owner>/<repo>/blob/<commit>/<path>#L14-L20
• <owner>/<repo> 应使用本次实际分析的代码仓库；如果引用的是上游依赖或外部仓库，就用那个仓库自己的链接。
• <commit> 必须是本次分析实际依据的代码版本：
  • 默认使用当前检出的 HEAD
  • 如果为了复核旧 issue 切到了某个 tag / commit，就使用那个版本解析后的 SHA
• 如果引用的是文档、配置样例或资源定义，也尽量给对应远端链接，而不是本地路径。

Output Format

最终回答用这个结构：

## Issue 概要

- issue：`#1234`
- 版本 / 分支 / 镜像 / 环境：
- API / 资源 / 相关配置：
- 用户现象：

## 证据概览

- 实际可读材料：
- 缺失或未上传的关键证据：

## 关键证据

- issue 正文 / 评论：
- Ingress / HTTP：
- 应用、PostgreSQL/MySQL、Redis：
- Kubernetes / 配置：
- 代码依据：如需指向具体实现，直接附远端 GitHub 行号链接。

## 根因判断

- 已证实的根因：
- 高概率怀疑点：
- 当前主线是否可能已修复：

## 修复方案

1. 代码、schema、配置或部署层修复
2. 需要补充的测试、日志、指标或集群证据
3. 临时缓解与回滚边界

## 置信度

- 高 / 中 / 低
- 还缺什么证据

Reminders

• 不要只看一个日志文件下结论。
• 不要把 issue 评论、机器人提示或维护者判断当成唯一证据。
• 不要把当前分支代码直接当成 issue 当时的真实环境。
• 日志和截图冲突时，优先解释冲突，再决定更可信的证据链。
• 如果问题本身没有在当前日志中复现，要明确写“证据未复现”，不要硬凑结论。
• 如果 issue 版本较旧，要明确区分“当时的根因”和“当前主线是否已修复”。
• 如果回答里出现任务名、入口名、设置项、按钮名、提示文案，优先先搜索项目里的翻译 / 本地化文件，再使用实际用户可见文案；必要时才补原始 key / id。
• 如果回答里引用了具体代码行，直接给远端 GitHub blob 行号链接，不要给本地路径加行号。
• 如果证据表明问题已在新版本修复，明确建议升级；如果怀疑安装包、资源文件或配置损坏，明确建议重建；如果判断为真实代码缺陷且暂无 workaround，明确建议等待修复。