Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Refactor chaterror.Classify to normalize evidence gathering

Abierto
#1,638 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, testing

Línea de trabajo

Empieza por coderd/x/chatd/chaterror/classify.go y después lee signals.go y provider_error.go para seguir cómo se recopilan y muestran actualmente el transporte y el texto de respuesta estructurado. Ejecuta las pruebas de señales existentes de chaterror y, después, haz que las fuentes de evidencia sean coherentes y añade la matriz de solo body/solo transporte descrita en el issue; se considera terminado cuando todas las señales se clasifiquen de forma idéntica independientemente de la fuente, sin cambiar la firma pública de Classify.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)
Lenguaje dominante
Sin datos de lenguaje
Estrellas
3
Forks
0
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de coder/internal

Todos los issues de coder/internal

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.