Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Refactor chaterror.Classify to normalize evidence gathering

オープン
#1,638 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
リファクタリング
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go
領域
backend, testing

調査の方向性

coderd/x/chatd/chaterror/classify.go から始め、次に signals.go と provider_error.go を読んで、現在 transport と構造化されたレスポンステキストがどのように収集され、表示されているかを追跡します。既存の chaterror シグナルテストを実行し、その後、証拠のソースを一貫させ、issue で説明されている body-only/transport-only のマトリックスを追加します。すべてのシグナルがソースに関係なく同一に分類され、Classify の公開シグネチャを変更しなければ完了です。

索引モデルが issue の本文から書いたものです。

説明

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)
主要言語
言語のデータがありません
スター
3
フォーク
0
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

coder/internal のほかの issue

coder/internal の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。