fix(server): adjust type of person.birthDate #16628
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ngc7293
force-pushed
the
david/fix-person-birthdate-return-type
branch
from
968fd25 to
3308d08
Compare
ngc7293
commented
Mar 6, 2025
Contributor
Author
There was a problem hiding this comment.
I edited this file manually. Whenever I tried to update it automatically, it would generate a large diff unrelated to my changes, some of which would cause compilation errors. Is this a known issue?
jrasm91
reviewed
Mar 6, 2025
Member
jrasm91
left a comment
jrasm91
left a comment
There was a problem hiding this comment.
We want it to parse dates automatically I think. It's a feature we've enabled on purpose. We also already have type mappings (like this) in the config.repository.ts file. I think the fix should be specifically in the person.dto mapper function
Contributor
Author
How did I miss those... I was going crazy to trying to figure out why the e2e tests were failing. Thanks for the info, I'll amend my PR. |
ngc7293
force-pushed
the
david/fix-person-birthdate-return-type
branch
3 times, most recently
from
024b207 to
52294f1
Compare
ngc7293
changed the title
ngc7293
force-pushed
the
david/fix-person-birthdate-return-type
branch
2 times, most recently
from
e119cfe to
7595b81
Compare
bo0tzz
reviewed
Mar 6, 2025
server/src/dtos/person.dto.ts
Outdated
| hasNextPage?: boolean; | ||
| } | ||
|
|
||
| const asDateString = (x: string | Date | null) => (x instanceof Date ? x.toISOString().split('T')[0] : x); |
Member
There was a problem hiding this comment.
Is this a dupe of the utils/date.ts below?
The API currently does not respect the documentation when returning a person's birthDate. The doc/swagger says it will be of "YYYY-MM-DD" format but the string is a full ISO8601-with-tz string. This causes issue immich-app#16216 because the <input> tag is strict about supported value formats. I believe this was introduced by immich-app#15242 which switched some queries from TypeORM to Kysely for the person repository. TypeORM does not parse date, but our Kysely configuration does (explicitely). This commits updates the types to represent both possibilities and ensure the API always returns the correct format.
ngc7293
force-pushed
the
david/fix-person-birthdate-return-type
branch
from
7595b81 to
2c33f19
Compare
alextran1502
approved these changes
Mar 6, 2025
jrasm91
approved these changes
Mar 6, 2025
knechtandreas
added a commit
to knechtandreas/immich
that referenced
this pull request
Mar 10, 2025
…s-broken * main: fix(server): set the dev server restart policy of the dev server container to match the other containers (immich-app#16753) feat(web): remember search context (immich-app#16614) feat(server): read Android and Sony video camera make/model (immich-app#16678) fix(server): adjust type of person.birthDate (immich-app#16628) fix(web): add labels to memory lane buttons (immich-app#16664) feat(mobile): locate in timeline (immich-app#16722) chore(ml): uv (immich-app#16725) fix: 🍪 packages confusion (immich-app#16735) fix(web): Update people-card favorite position (immich-app#16746) chore(mobile): upgrade riverpod (immich-app#16742) chore(mobile): upgrade flutter_web_auth_2 (immich-app#16741) fix(docs): edge case when restoring dump that is unreadable as current user (immich-app#16758)
1 task
This was referenced Apr 25, 2025
savely-krasovsky
pushed a commit
to savely-krasovsky/immich
that referenced
this pull request
Jun 8, 2025
The API currently does not respect the documentation when returning a person's birthDate. The doc/swagger says it will be of "YYYY-MM-DD" format but the string is a full ISO8601-with-tz string. This causes issue immich-app#16216 because the <input> tag is strict about supported value formats. I believe this was introduced by immich-app#15242 which switched some queries from TypeORM to Kysely for the person repository. TypeORM does not parse date, but our Kysely configuration does (explicitely). This commits updates the types to represent both possibilities and ensure the API always returns the correct format.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
The API currently does not respect the documentation when returning a person's birthDate. The doc/swagger says it will be of "YYYY-MM-DD" format but the string is a full ISO8601-with-tz string. This causes issue #16216 because the tag is strict about supported value formats.
I believe this was introduced by #15242 which switched some queries from TypeORM to Kysely for the person repository. TypeORM does not parse date, but our Kysely configuration does (explicitely).
This commits updates the types to represent both possibilities and ensure the API always returns the correct format.
Fixes #16216
How Has This Been Tested?
person/:id/(for a person with an age)photo/:id/(for an asset with a face)Screenshots (if appropriate)
API Changes
/person/:id/now correctly returnsbirthDateasYYYY-MM-DDinstead of full ISO8601-with-tzChecklist:
src/servicesuses repositories implementations for database calls, filesystem operations, etc.src/repositories/is pretty basic/simple and does not have any immich specific logic (that belongs insrc/services)