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

Document or refactor nullable-but-required pattern for timestamp fields across all destination types

Abierto
  • ¿Algo no está bien?
#526 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
30/100
Tipo de issue
Documentación
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
openapi
Área
api

Línea de trabajo

Start with docs/apis/openapi.yaml and compare the destination schemas, beginning with the GCP Pub/Sub implementation referenced in the issue. Decide whether to document the required-but-nullable semantics or make the fields optional, then apply the chosen approach consistently across all destination types. Done means the schemas follow one clear, consistent approach.

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

Descripción

Context

Multiple destination types have disabled_at and other timestamp fields marked as required but nullable in the OpenAPI specification.

Problem

This pattern is semantically confusing - "required but can be null" means "must be present but value can be null". While this is technically valid in OpenAPI, it can be unclear to API consumers and SDK users.

Current Behavior

This pattern is consistent across all destination types, which is correct behavior. The fields are present in responses but may have null values.

Options to Consider

  1. Document the pattern clearly - Add comments in the OpenAPI spec explaining why these fields use the nullable-but-required pattern
  2. Make fields optional - Remove from required array and handle absence vs null differently in the implementation
  3. Keep current pattern with schema documentation - Maintain current approach but add clear documentation explaining the semantics

Acceptance Criteria

  • Either document the nullable-but-required pattern clearly in the OpenAPI spec, OR
  • Refactor to use optional fields consistently across all destination type schemas
  • Ensure chosen approach is applied consistently across ALL destination types

Reference

Identified in code review of GCP Pub/Sub implementation. This is a systemic pattern that affects all destination types.

Related Files

  • docs/apis/openapi.yaml - All destination schemas
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.