Repository navigation
fix: preserve concurrent Personal Info field updates - #172
Open
rudycelekli wants to merge 1 commit into
Open
rudycelekli wants to merge 1 commit into
rudycelekli wants to merge 1 commit into
Conversation
Signed-off-by: Rudy Celekli <rudy@gradiahq.com>
This branch has not been deployed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Preserve unrelated Personal Info fields when separate conversations update the same user's profile concurrently.
personal_info.updatepasses a field patch topatchUserProfile. The service previously read the full profile, merged the patch in memory, then upserted the entire row. Two overlapping updates could read the same old row and the later write erased the other conversation's field.Use one field-only
INSERT … ON CONFLICT DO UPDATE … RETURNINGoperation. Insert defaults cover the first profile, while conflict updates write only explicitly supplied fields. Country code normalization, explicit null clearing and full profile replacement keep their existing behavior.Reproduction and tests
The new regression uses committed migrations and a real PGlite/Drizzle database. It invokes the actual Personal Info update tool from two independently owned conversation contexts sharing one fixture user. On the unchanged source, concurrently setting city and region loses city. Concurrently creating first and last names also loses one field: 2 fail / 2 pass before. No SQL results, reads, or write ordering are mocked. Only the database driver boundary is swapped for isolated PGlite.
After the fix, all four new cases plus eight existing profile-memory controls pass (12/12). Controls cover normalization, clearing a supplied field, preserving unrelated fields, initial insertion, and intentional full replacement.
Required local gates with declared Node 24 and pnpm 11.24.0:
pnpm check: 96 files / 880 tests, lint, types, formatting and Knip pass.pnpm build: passes with owned placeholder database/Kernel settings; no deployment or live integration claim.pnpm test:runtime: two isolated mock-model workflow evals and 13 gates displayed passing, but the command exited 1 after the shipped 180-second cleanup timeout. Its Eve CLI was stuck in an owneddocker pscleanup subprocess on this host; this local command is not counted as a pass.The unchanged declared Checks workflow completed successfully on the exact signed source head
7bfe483f4baa05852a6afe2194455860597a4da2. Hostedpnpm checkpassed 96 files / 880 tests and all six check tasks. Hostedpnpm test:runtimecompleted successfully: both isolated mock-model workflow evals passed all 13 gates, including cleanup. The run used Node 24.21.0 from the declared Node 24 version and pnpm 11.24.0 with the frozen lockfile. The PR merge checkout tree matches the reviewed source head; no workflow, dependency or runtime fixture changes were made.The focused regression directly exercises the provider tool and real PostgreSQL-compatible database. It does not run a live model, production authentication, or a deployed PostgreSQL server. The separate runtime smoke gate covers the repository's unchanged supported workflow fixtures.
Scope and overlap
No schema, migration, auth, UI, dependency or workflow changes. Current 14 open PRs and 10 issues were screened; none overlap this service/tool cause. One source fix with four regression controls.
AI assistance was used for investigation, implementation, tests and review under the submitting account. Signed DCO commit included.