Update OpenAPI schema by dotto-api-schema-updater[bot] · Pull Request #14 · fun-dotto/user-api

dotto-api-schema-updater · 2026-04-19T09:29:22Z

This PR updates the OpenAPI schema from dotto-typespec.

Triggered by: fun-dotto/dotto-typespec@b43c097

notifyAfter/notifyBefore への分割と通知一括送信エンドポイントの追加に追従する。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

StrictServerInterface を満たすため NotificationV1Dispatch を追加し、一旦 not implemented を返す。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

API 側の notifyAt が notifyAfter/notifyBefore に分割されたため、ビルド維持のため一旦 domain.NotifyAt を両フィールドへ射影し、リクエスト側は notifyAfter から取り込む。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

This PR syncs this service’s OpenAPI contract (and generated server bindings) with updates from dotto-typespec, notably expanding the notification scheduling model and adding a new dispatch endpoint.

Changes:

Updated notification filtering descriptions and replaced notifyAt with notifyAfter/notifyBefore in schemas.
Added POST /v1/notifications/dispatch to the OpenAPI spec and regenerated server types/handlers.
Updated handler converter mappings to compile with the new generated models.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 6 comments.

File	Description
openapi/openapi.yaml	Updates notification schema fields and adds the `/dispatch` endpoint contract.
internal/handler/notification_dispatch.go	Adds the new strict handler method stub for dispatch.
internal/handler/converter.go	Adjusts domain↔API conversion for new `notifyAfter`/`notifyBefore` fields.
generated/api.gen.go	Regenerates Go types and routes from the updated OpenAPI spec.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-21T05:00:53Z

+		NotifyAfter:   n.NotifyAt,
+		NotifyBefore:  n.NotifyAt,


notifyAfter と notifyBefore をどちらも domain.Notification.NotifyAt にマッピングしているため、APIの「送信可能期間（ウィンドウ）」という新しい意味を表現できず、レスポンスが常に同一時刻になります。ドメイン/DB側で NotifyAfter / NotifyBefore を保持できるように拡張するか、少なくとも現状のモデル制約（単一時刻しか保持できない）に合わせてOpenAPI側を戻す/互換フィールドを残すなど、API仕様と実装を一致させてください。

Copilot · 2026-04-21T05:00:54Z

 func toDomainNotification(id string, req api.NotificationRequest) domain.Notification {
 	return domain.Notification{
 		ID:            id,
 		Title:         req.Title,
 		Message:       req.Message,
 		URL:           req.Url,
-		NotifyAt:      req.NotifyAt,
+		NotifyAt:      req.NotifyAfter,
 		TargetUserIDs: req.TargetUserIds,
 	}


NotificationRequest で必須になった notifyBefore が toDomainNotification で一切使われていないため、クライアントが指定した送信期限が保存されずデータ欠落になります。notifyAfter/notifyBefore の整合性（例: after <= before）を検証した上で、ドメインモデルへ両方を反映するか、現状単一時刻しか保持できないなら両者が同一であることを検証してエラーにする等の扱いを決めてください。

Copilot · 2026-04-21T05:00:54Z

+          description: '通知予定期間の開始日時（通知ウィンドウがこの範囲と重なるものを抽出: notifyBefore >= notifyAtFrom）'
          schema:
            type: string
            format: date-time
        - name: notifyAtTo
          in: query
          required: false
-          description: 通知予定日時の終了日時 (notifyAt <= notifyAtTo)
+          description: '通知予定期間の終了日時（通知ウィンドウがこの範囲と重なるものを抽出: notifyAfter <= notifyAtTo）'


notifyAtFrom/notifyAtTo の説明が「通知ウィンドウの重なり（notifyBefore >= from, notifyAfter <= to）」になっていますが、現状の実装は notify_at >= from / notify_at <= to の単一時刻フィルタです（internal/repository/notification_list.go）。APIの実際の挙動と乖離するので、説明を現実のフィルタ条件に戻すか、実装側を説明通りの条件に更新してください。

Copilot · 2026-04-21T05:00:54Z

+              type: object
+              properties:
+                notificationIds:
+                  type: array
+                  items:
+                    type: string
+              required:
+                - notificationIds


notificationIds が空配列の場合に 400 を返す仕様ですが、スキーマに minItems: 1 が無いため OpenAPI バリデーションでは空配列を弾けません（結果として実装側での手動チェックが必須になります）。仕様通りにするなら notificationIds に minItems: 1 を追加してください。

Copilot · 2026-04-21T05:00:54Z

+                required:
+                  - notifications
+        '400':
+          description: The server could not understand the request due to invalid syntax.


400 レスポンスの説明が「invalid syntax」になっていますが、このエンドポイントで想定している 400 は「notificationIds が空配列」のようなバリデーションエラーです。クライアントに誤解を与えるので、400 の説明を実際の条件に合わせるか、エラー本文スキーマ（例: message/code）を定義して明確にしてください。

Suggested change

description: The server could not understand the request due to invalid syntax.

description: リクエストのバリデーションエラー。たとえば `notificationIds` が空配列の場合に返される。

content:

application/json:

schema:

type: object

properties:

message:

type: string

description: バリデーションエラーの内容

code:

type: string

description: エラー種別を表すコード

required:

- message

- code

example:

message: notificationIds must not be empty

code: VALIDATION_ERROR

Copilot · 2026-04-21T05:00:55Z

+	"fmt"
+
+	api "github.com/fun-dotto/user-api/generated"
+)
+
+func (h *Handler) NotificationV1Dispatch(_ context.Context, _ api.NotificationV1DispatchRequestObject) (api.NotificationV1DispatchResponseObject, error) {
+	return nil, fmt.Errorf("not implemented")


このハンドラが未実装で常にエラーを返すため、strict handler の挙動により /v1/notifications/dispatch は常に HTTP 500 になります（OpenAPIでは 200/400 のみ定義）。少なくとも仕様に合わせて 400/200 の ResponseObject を返す実装を追加するか、実装が入るまでルート/スキーマを公開しないようにしてください。

Suggested change

"fmt"

api "github.com/fun-dotto/user-api/generated"

)

func (h *Handler) NotificationV1Dispatch(_ context.Context, _ api.NotificationV1DispatchRequestObject) (api.NotificationV1DispatchResponseObject, error) {

return nil, fmt.Errorf("not implemented")

api "github.com/fun-dotto/user-api/generated"

)

func (h *Handler) NotificationV1Dispatch(_ context.Context, _ api.NotificationV1DispatchRequestObject) (api.NotificationV1DispatchResponseObject, error) {

var resp api.NotificationV1Dispatch400JSONResponse

return resp, nil

Update OpenAPI schema from dotto-typespec

9daec90

kantacky self-assigned this Apr 21, 2026

kantacky and others added 3 commits April 21, 2026 13:55

OpenAPI スキーマ差分から生成コードを再生成

7cd9a27

notifyAfter/notifyBefore への分割と通知一括送信エンドポイントの追加に追従する。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

通知一括送信エンドポイントの未実装ハンドラを追加

4a97bd6

StrictServerInterface を満たすため NotificationV1Dispatch を追加し、一旦 not implemented を返す。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

kantacky marked this pull request as ready for review April 21, 2026 04:57

kantacky requested review from a team, Copilot, hikaru-0602, kantacky and masaya-osuga April 21, 2026 04:57

kantacky approved these changes Apr 21, 2026

View reviewed changes

Copilot started reviewing on behalf of kantacky April 21, 2026 04:57 View session

kantacky merged commit 9390a9d into main Apr 21, 2026
4 checks passed

kantacky deleted the update-openapi-schema branch April 21, 2026 04:58

Copilot AI reviewed Apr 21, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update OpenAPI schema#14

Update OpenAPI schema#14
kantacky merged 4 commits intomainfrom
update-openapi-schema

dotto-api-schema-updater Bot commented Apr 19, 2026

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 21, 2026

Uh oh!

Copilot AI Apr 21, 2026

Uh oh!

Copilot AI Apr 21, 2026

Uh oh!

Copilot AI Apr 21, 2026

Uh oh!

Copilot AI Apr 21, 2026

Uh oh!

Copilot AI Apr 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-          description: The server could not understand the request due to invalid syntax.
+          description: リクエストのバリデーションエラー。たとえば `notificationIds` が空配列の場合に返される。
+          content:
+            application/json:
+              schema:
+                type: object
+                properties:
+                  message:
+                    type: string
+                    description: バリデーションエラーの内容
+                  code:
+                    type: string
+                    description: エラー種別を表すコード
+                required:
+                  - message
+                  - code
+              example:
+                message: notificationIds must not be empty
+                code: VALIDATION_ERROR

Conversation

dotto-api-schema-updater Bot commented Apr 19, 2026

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 21, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants