Skip to content

fix: validate effective_at against new invalid_at when both updated #13

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Washio20 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix: validate effective_at against new invalid_at when both updated #13

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions openapi.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -657,7 +657,7 @@
}
},
"422": {
"description": "Unprocessable Entity - Request is well-formed but contains semantic errors.\nError codes: `unprocessable_entity`\n",
"description": "Unprocessable Entity - Request is well-formed but contains semantic errors.\nFor time validation: `effective_at` must be earlier than `invalid_at`. When both fields are provided in the same request, they are validated against each other (the new values), not against the currently stored values.\nError codes: `unprocessable_entity`\n",
Copy link

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The time validation documentation was added only to the PATCH endpoint's 422 error description, but the CardProperties schema is also used by the POST endpoint (via CardInput). If the time validation logic applies to POST requests as well (when both effective_at and invalid_at are provided), consider adding similar documentation to the POST endpoint's 422 error description (line 318 in openapi.json). This would ensure consistency and clarity for API consumers using either endpoint.

Copilot uses AI. Check for mistakes.
"content": {
"application/json": {
"schema": {
Expand Down Expand Up @@ -7090,13 +7090,13 @@
"type": "string",
"format": "date-time",
"nullable": true,
"description": "Effective time (when the card becomes active).\nMust be the current time or a future time.\n**⚠️Default: `UTC`**, recommended to use the format `2025-02-16T12:00:00+01:00` to ensure the correct time zone.\nAbout ISO 8601: https://en.wikipedia.org/wiki/ISO_8601\n"
"description": "Effective time (when the card becomes active).\nMust be the current time or a future time, and must be earlier than `invalid_at`.\nWhen updating both `effective_at` and `invalid_at` in a single PATCH request, `effective_at` is validated against the new `invalid_at` value provided in the request body (not the currently stored `invalid_at`).\n**⚠️Default: `UTC`**, recommended to use the format `2025-02-16T12:00:00+01:00` to ensure the correct time zone.\nAbout ISO 8601: https://en.wikipedia.org/wiki/ISO_8601\n"
Copy link

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description mentions "When updating both effective_at and invalid_at in a single PATCH request", but since CardProperties is also used by CardInput for POST requests, this wording might be confusing. Consider either:

  1. Using more generic wording like "When both fields are provided in the same request" (similar to the 422 error description), or
  2. Explicitly mentioning both POST and PATCH operations if the validation applies to both.
    This would make the documentation clearer for API consumers using the POST endpoint.

Copilot uses AI. Check for mistakes.
},
"invalid_at": {
"type": "string",
"format": "date-time",
"nullable": true,
"description": "Invalidation time (when the card becomes invalid/expires).\nMust be the current time or a future time.\n**⚠️Default: `UTC`**, recommended to use the format `2025-02-16T12:00:00+01:00` to ensure the correct time zone.\nAbout ISO 8601: https://en.wikipedia.org/wiki/ISO_8601\n"
"description": "Invalidation time (when the card becomes invalid/expires).\nMust be the current time or a future time, and must be later than `effective_at`.\nWhen updating both `effective_at` and `invalid_at` in a single PATCH request, `invalid_at` is validated against the new `effective_at` value provided in the request body (not the currently stored `effective_at`).\n**⚠️Default: `UTC`**, recommended to use the format `2025-02-16T12:00:00+01:00` to ensure the correct time zone.\nAbout ISO 8601: https://en.wikipedia.org/wiki/ISO_8601\n"
Copy link

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description mentions "When updating both effective_at and invalid_at in a single PATCH request", but since CardProperties is also used by CardInput for POST requests, this wording might be confusing. Consider either:

  1. Using more generic wording like "When both fields are provided in the same request" (similar to the 422 error description), or
  2. Explicitly mentioning both POST and PATCH operations if the validation applies to both.
    This would make the documentation clearer for API consumers using the POST endpoint.

Copilot uses AI. Check for mistakes.
},
"barcode_type": {
"type": "string",
Expand Down
16 changes: 14 additions & 2 deletions openapi.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -502,6 +502,10 @@ paths:
description: 'Unprocessable Entity - Request is well-formed but contains
semantic errors.

For time validation: `effective_at` must be earlier than `invalid_at`.
When both fields are provided in the same request, they are validated
against each other (the new values), not against the currently stored values.
Comment on lines +505 to +507
Copy link

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The time validation documentation was added only to the PATCH endpoint's 422 error description, but the CardProperties schema is also used by the POST endpoint (via CardInput). If the time validation logic applies to POST requests as well (when both effective_at and invalid_at are provided), consider adding similar documentation to the POST endpoint's 422 error description (lines 236-242 in openapi.yaml). This would ensure consistency and clarity for API consumers using either endpoint.

Copilot uses AI. Check for mistakes.

Error codes: `unprocessable_entity`

'
Expand Down Expand Up @@ -5536,7 +5540,11 @@ components:
nullable: true
description: 'Effective time (when the card becomes active).

Must be the current time or a future time.
Must be the current time or a future time, and must be earlier than `invalid_at`.

When updating both `effective_at` and `invalid_at` in a single PATCH request,
`effective_at` is validated against the new `invalid_at` value provided in
the request body (not the currently stored `invalid_at`).
Comment on lines +5545 to +5547
Copy link

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description mentions "When updating both effective_at and invalid_at in a single PATCH request", but since CardProperties is also used by CardInput for POST requests, this wording might be confusing. Consider either:

  1. Using more generic wording like "When both fields are provided in the same request" (similar to the 422 error description), or
  2. Explicitly mentioning both POST and PATCH operations if the validation applies to both.
    This would make the documentation clearer for API consumers using the POST endpoint.

Copilot uses AI. Check for mistakes.

**⚠️Default: `UTC`**, recommended to use the format `2025-02-16T12:00:00+01:00`
to ensure the correct time zone.
Expand All @@ -5550,7 +5558,11 @@ components:
nullable: true
description: 'Invalidation time (when the card becomes invalid/expires).

Must be the current time or a future time.
Must be the current time or a future time, and must be later than `effective_at`.

When updating both `effective_at` and `invalid_at` in a single PATCH request,
`invalid_at` is validated against the new `effective_at` value provided in
the request body (not the currently stored `effective_at`).
Comment on lines +5563 to +5565
Copy link

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The description mentions "When updating both effective_at and invalid_at in a single PATCH request", but since CardProperties is also used by CardInput for POST requests, this wording might be confusing. Consider either:

  1. Using more generic wording like "When both fields are provided in the same request" (similar to the 422 error description), or
  2. Explicitly mentioning both POST and PATCH operations if the validation applies to both.
    This would make the documentation clearer for API consumers using the POST endpoint.

Copilot uses AI. Check for mistakes.

**⚠️Default: `UTC`**, recommended to use the format `2025-02-16T12:00:00+01:00`
to ensure the correct time zone.
Expand Down
Loading