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>
|
1 participant
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