[EDIFIKANA] Make createProperty atomic via RPC (DS-PROP-010) - #579
Merged
Conversation
5 tasks
CRamsan
force-pushed
the
cr/ds-x-009-fk-cascade-sweep
branch
from
July 27, 2026 07:20
5dd6c2e to
4f14e96
Compare
added 11 commits
July 27, 2026 00:22
…og (NONE) DS-X-009 (property-side RESTRICT-vs-CASCADE sweep) already existed and passes live -- discovered during implementation, not written as part of this work. Adds DS-X-009b to the catalog for the newly-added unit-side sweep test, and reframes Finding #6 from speculative to confirmed with the observed outcome.
… RPC (NONE) createProperty previously issued two separate Postgrest inserts (properties, then user_property_mapping) with nothing wrapping them, so a failure on the second call left an orphaned, ownerless property row behind. Both inserts now run inside a single RPC call, which Postgres executes as one transaction.
Confirms createProperty's new atomic RPC leaves no orphaned property row behind when the owner-mapping insert fails on a nonexistent creatorUserId.
CRamsan
force-pushed
the
cr/ds-prop-010-atomic-create-property
branch
from
July 27, 2026 07:22
d8697ea to
e9f4681
Compare
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
1 participant
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
createPropertypreviously issued two separate Postgrest inserts (properties, thenuser_property_mapping) with nothing wrapping them. If the second insert failed for anyreason, the property from the first insert was already committed — an orphaned, ownerless
property, permanently invisible via
getProperties(userId)for every user.create_property_with_ownerRPC (new migration),mirroring the existing
upsert_rent_config/transfer_ownershipatomicity pattern — Postgresexecutes one RPC call as one transaction, so a failure on either insert rolls back both.
PropertyEntity.CreatePropertyEntitymodel and itsSupabaseMappers.ktfactory function, since nothing constructs the old two-step insert payload anymore.
datastore-test-catalog.md(Finding Build Tech Doc #3 /DS-PROP-010) to record the fix.Demo
N/A — no UI changes.
References
Test plan
./gradlew :edifikana:back-end:release --quiet— clean buildDS-PROP-010b createProperty should not leave an orphaned property row when the owner mapping insert fails— fabricates a nonexistentcreatorUserId(FK violation), confirmsResult.isFailure, and confirms via a raw untyped select that no orphanedpropertiesrow survivesDS-PROP-010 createProperty should create both the property and its owning user_property_mapping(happy path) still passes unmodified against the new RPC-backed implementation./gradlew :edifikana:back-end:integTest --tests "*SupabasePropertyDatastoreIntegrationTest*"— all pass./gradlew :edifikana:back-end:integTest(full suite) — 264/264 pass, no regressions