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

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

オープン
  • 何か問題がありますか？
#526 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
30/100
issue の種類
ドキュメント
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
openapi
領域
api

調査の方向性

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.

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

説明

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
主要言語
Go
スター
1.1k
フォーク
70
平均マージ
1日 18時間
マージ済み PR（30日）
56

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

hookdeck/outpost のほかの issue

hookdeck/outpost の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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