Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Refactor chaterror.Classify to normalize evidence gathering

Đang mở
#1,638 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
45/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go
Lĩnh vực
backend, testing

Hướng nghiên cứu

Bắt đầu với coderd/x/chatd/chaterror/classify.go, sau đó đọc signals.go và provider_error.go để theo dõi cách transport và văn bản phản hồi có cấu trúc hiện được thu thập và hiển thị. Chạy các bài kiểm thử signal hiện có của chaterror, sau đó làm cho các nguồn bằng chứng nhất quán và thêm ma trận chỉ-body/chỉ-transport được mô tả trong issue; hoàn tất khi tất cả signal được phân loại giống hệt nhau bất kể nguồn nào, mà không thay đổi chữ ký public của Classify.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Note: this issue was filed by an over-eager agent with too many MCP tools.

Context

PR coder/coder#27913 fixed a bug where a Bedrock credential resolution failure was incorrectly retried as a generic 500. The fix widened several signal checks in chaterror.Classify to read combinedText (the merged transport wrapper + structured response body) instead of lower (just the wrapper).

This exposed a structural issue: the classifier has two parallel text sources (lower from err.Error() and structured.detail from ProviderError.ResponseBody) and signal checks inconsistently pick which to match against. PR coder/coder#27913 widened the body-only signals, but the underlying design is fragile.

Problems

  1. Two-source inconsistency: Some signals check lower, some check combinedText, and it is unclear which uses which without reading each line. New signal checks can silently regress to lower-only.

  2. Pattern sprawl: Too many string patterns across too many signal lists (overloadedPatterns, authStrongPatterns, configPatterns, timeoutPatterns, etc.) without documentation of which provider incident motivated each pattern.

  3. Signal/display coupling: structured.detail (used for signal matching) is the first line of the response body only (providerErrorResponseMessage truncates at the first newline). If the useful signal text appears on line 2+, it is missed. The signal source and the user-facing detail display are the same string; they should be decoupled.

Proposed approach

Data-flow normalization, not a rule engine:

  1. One gatherEvidence step at the top of Classify that produces a single struct: lowercased combined text (transport error + full structured body, not just first line), status code, and any structured provider fields.
  2. Every signal check reads only from the evidence struct. No signal touches raw inputs.
  3. Keep the prioritized rule ordering as plain Go code. Do not build a pattern-matching DSL or data-driven rule table.
  4. Decouple signal matching text from user-facing detail display text.

Non-goals

  • No new error taxonomy.
  • No change to Classify's public signature.
  • No pattern DSL or data-driven rule engine.

Test strategy

Convert signal tests to a matrix that programmatically asserts each source-agnostic signal classifies correctly when the pattern arrives via body-only and via transport-only. This makes "forgot to check the other source" impossible to reintroduce silently.

Related

  • PR coder/coder#27913 (the incremental fix)
  • coderd/x/chatd/chaterror/classify.go (the classifier)
  • coderd/x/chatd/chaterror/signals.go (the pattern definitions)
  • coderd/x/chatd/chaterror/provider_error.go (response body extraction)
Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
3
Fork
0
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của coder/internal

Tất cả issue của coder/internal

Issue tương tự

Thêm issue về Backend & API Design

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.