fix(geo-data): correct country_id mismatch in states.csv and cities.csv#1682
fix(geo-data): correct country_id mismatch in states.csv and cities.csv#1682YogeshK34 wants to merge 2 commits into
Conversation
📝 WalkthroughWalkthroughThe seed script now fills ChangesPlatform user seeding
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Signed-off-by: yogeshk34 <khutwadyogesh34@gmail.com>
YogeshK34
force-pushed
the
fix/geo-data-clean
branch
from
95f2de6 to
3fcc25b
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@libs/prisma-service/prisma/seed.ts`:
- Around line 190-192: `seed.ts` currently reuses the first result from
`prisma.user.findMany` without validating `PLATFORM_ADMIN_EMAIL`, which can
accidentally match any user when the env var is missing. Update the
`platformUserId` lookup logic to fail fast if `PLATFORM_ADMIN_EMAIL` is unset,
and switch the user lookup to `findUnique` in the platform admin branch so the
unique `email` field is used safely before assigning
`existPlatformAdminUser[0].id`.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9b31560c-6a42-4670-b115-7f6252048603
⛔ Files ignored due to path filters (1)
libs/prisma-service/prisma/data/geo-location-master-data/cities.csvis excluded by!**/*.csv
📒 Files selected for processing (1)
libs/prisma-service/prisma/seed.ts
| // User already exists — still need to set platformUserId so downstream | ||
| // functions (createPlatformOrganization) have a valid UUID for createdBy/lastChangedBy | ||
| platformUserId = existPlatformAdminUser[0].id; |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify whether PLATFORM_ADMIN_EMAIL is validated anywhere before the Prisma lookup.
fd seed.ts . | xargs -I{} sh -c '
echo "== {} =="
sed -n "150,220p" "{}"
echo
rg -n "PLATFORM_ADMIN_EMAIL|findMany\\(|findUnique\\(" "{}"
'Repository: credebl/platform
Length of output: 3849
🌐 Web query:
Does Prisma Client ignore undefinedvalues inwherefilters, and isfindUnique({ where: { email } }) the recommended API for a unique email column?
💡 Result:
Prisma Client behavior regarding undefined values in where filters is as follows: When you pass undefined as a value in a where filter, Prisma Client effectively ignores that filter criteria, as if it had not been provided at all [1][2]. This can lead to unexpected behavior, such as returning all records when you intended to filter by none [3][4]. To mitigate this, you can enable the strictUndefinedChecks preview feature (available in version 5.20.0 and later), which causes explicit undefined values to throw a runtime error and requires the use of Prisma.skip to intentionally omit a field [1][5]. Regarding the recommended API for a unique email column, findUnique({ where: { email } }) is indeed the correct and recommended API, provided that the email field is marked as @unique in your Prisma schema [6][7]. If the field is not marked as @unique, Prisma Client will not allow you to use it in a findUnique query; in such cases, you would receive an error and would need to either mark the field as unique or use findFirst instead [8][9][10].
Citations:
- 1: https://www.prisma.io/docs/orm/prisma-client/special-fields-and-types/null-and-undefined
- 2: https://github.com/prisma/specs/blob/master/prisma-client-js/README.md
- 3: findMany returns all objects when
whereis undefined. prisma/prisma#9124 - 4:
undefinedinwherequery prisma/prisma#10220 - 5: https://www.prisma.io/docs/orm/v6/prisma-client/special-fields-and-types/null-and-undefined
- 6: https://www.prisma.io/docs/orm/reference/prisma-client-reference
- 7: https://www.prisma.io/docs/orm/prisma-client/queries/crud
- 8: findUnique is not working with variables different from "id" prisma/prisma#10791
- 9: https://stackoverflow.com/questions/67951796/prisma-findunique-with-where-throws-an-error
- 10: Issue using findUnique in Typescript prisma/prisma#8341
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the Prisma user model and nearby seed logic to confirm whether email is unique
# and whether PLATFORM_ADMIN_EMAIL is handled elsewhere.
echo "== seed.ts excerpt =="
sed -n '160,215p' libs/prisma-service/prisma/seed.ts
echo
echo "== user model references =="
rg -n "model User|model user|`@unique`|email" libs/prisma-service/prisma -g '*.prisma'Repository: credebl/platform
Length of output: 4876
Validate PLATFORM_ADMIN_EMAIL before reusing the first user record.
If this env var is missing, prisma.user.findMany({ where: { email: undefined } }) drops the filter and existPlatformAdminUser[0].id can come from an arbitrary user. Fail fast here and switch to findUnique since email is unique.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@libs/prisma-service/prisma/seed.ts` around lines 190 - 192, `seed.ts`
currently reuses the first result from `prisma.user.findMany` without validating
`PLATFORM_ADMIN_EMAIL`, which can accidentally match any user when the env var
is missing. Update the `platformUserId` lookup logic to fail fast if
`PLATFORM_ADMIN_EMAIL` is unset, and switch the user lookup to `findUnique` in
the platform admin branch so the unique `email` field is used safely before
assigning `existPlatformAdminUser[0].id`.
|
Hey @tipusinghaw & @ankita-p17, There was a merge conflict on Would like your feedback |
…pstream Signed-off-by: yogeshk34 <khutwadyogesh34@gmail.com>
|
Hi @YogeshK34 it seems your changes are already accomodates in any recent PR, hence there is only one change is coming in seed file. This change is already there is another PR - #1678 |
|
@ankita-p17 I noticed #1690 has the exact same fix as my PR, a new PR was created a week later by @KambleSahil3. I don't know if this was a coincidence of some kind, but was my PR #1682 the basis for that fix? Asking because no reference was made to this PR and it's still open. Wanted to flag this for transparency. |
Hi @YogeshK34, thanks for raising this. |
2 participants
Problem
states.csvcontains a systematiccountry_idcorruption affecting all countries from Germany onward (~148 countries). Thecountry_codecolumn is correct, butcountry_idvalues don't match the IDs incountries.csv— causing states of one country to be served under another.Example:
This means selecting India in the UI returned Iran's states. Selecting Hong Kong returned India's states. No error is thrown — the data is silently wrong.
cities.csvhad the same downstream corruption.Root Cause
The
country_idcolumn was not derived fromcountries.csvIDs. Thecountry_codecolumn was always correct, butcountry_iddiverged for ~148 countries starting alphabetically around Germany.Fix
Regenerated
country_idin both CSVs by mappingcountry_code(ISO) → correctidfromcountries.csv.states.csv— 4,581 rows correctedcities.csv— 105,446 rows correctedImpact
Testing
Note
Supersedes #1681 — this PR isolates only the geo-data fix.
Summary by CodeRabbit