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

Attempts for no-response delivery failures carry no diagnostic information

Abierto
  • ¿Algo no está bien?
#1,028 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
api, backend

Línea de trabajo

Read the discussion on PR #1018 and compare the two response_data design positions described here before changing behavior. Trace how connection-level failures, format failures, and publisher-resolution failures are recorded, and review the attempt model, log store schemas, API type, and SDKs if choosing a dedicated field. Done means no-response attempts expose useful diagnostics assembled only from allowlisted data, without persisting raw transport error strings; the EADDRNOTAVAIL classification is a separate, severable change.

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

Descripción

destination

Problem

When a webhook delivery fails before receiving an HTTP response — DNS failure, connection refused, TLS error, dial timeout — the attempt records a code and nothing else. response_data is NULL.

failure code response_data
destination returns 4xx/5xx "503" status, body
payload format failure "ERR" the error message
publisher resolution failure "ERR" the error message
connection-level failure connection_refused, dns_error, network_error, … NULL

A destination that returns a 500 with an empty body leaves more diagnostic trace than one that could not be reached at all. The network_error catch-all is the worst case: an attempt with that code carries no information whatsoever, so the end user cannot distinguish "my DNS points at a stale IP" from "my service is down" from "my TLS cert expired" without contacting support.

Constraints on a fix

Message content must be safe by construction. Raw Go transport error strings cannot be stored verbatim: proxy failures embed operator-side proxy diagnostics, net.OpError can include a source (pod) address, and errno text reveals sender-host state. Any recorded cause should be assembled from allowlisted parts — classification code, the customer-configured destination host/port, optionally the resolved IP — never from err.Error() passthrough.

Field design needs a decision. Two positions:

  1. response_data is the attempt's explanation field and the name is historical. Two existing no-response paths (format failure, publisher resolution) already store {"error": ...} there, and NewFormatError's doc comment calls it "the customer-facing string persisted on the attempt."
  2. response_data should strictly mean an HTTP response, and failure causes belong in a dedicated field (failure_reason / error) — cleaner, but touches models.Attempt, both log store schemas, the API type, the SDKs, and the {"error": ...} values already in customers' attempt histories.

The inconsistency is customer-visible either way, so whichever path a fix takes should settle this first.

Prior art

PR #1018 implemented position 1 with raw err.Error() on the non-proxy path (proxy errors already stored classification only). Parked: no user demand yet, and the raw passthrough could not be proven leak-free. See discussion there.

Related, severable piece from that PR: classifying source-side ephemeral port exhaustion (EADDRNOTAVAIL) as address_unavailable instead of the network_error catch-all, so sender-side failures are not charged to the destination.

Lenguaje dominante
Go
Estrellas
1.1k
Forks
70
Merge medio
1 d 18 h
PR fusionados (30 d)
56

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 hookdeck/outpost

Todos los issues de hookdeck/outpost

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.