Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Refactor chaterror.Classify to normalize evidence gathering

Aperta
#1,638 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend, testing

Direzione di ricerca

Inizia da coderd/x/chatd/chaterror/classify.go, poi leggi signals.go e provider_error.go per tracciare come vengono attualmente raccolti e visualizzati il trasporto e il testo della risposta strutturata. Esegui i test dei segnali chaterror esistenti, quindi rendi coerenti le fonti delle evidenze e aggiungi la matrice solo-body/solo-trasporto descritta nell’issue; il lavoro è completato quando tutti i segnali vengono classificati in modo identico indipendentemente dalla fonte, senza modificare la firma pubblica di Classify.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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)
Lingua principale
Nessun dato sulla lingua
Stelle
3
Fork
0
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di coder/internal

Tutte le issue di coder/internal

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.