fix(roles): make member-role assignment idempotent #102
No reviewers
Labels
No labels
area:api
area:core
area:docs
area:infra
area:ux
dependencies
documentation
duplicate
good first issue
help wanted
invalid
question
rust
status:complete
status:partial
status:planned
type:bug
type:design
type:feature
type:infra
type:refactor
type:refactor
type:research
type:ux
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
icub3d/decentcom!102
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/idempotent-member-role"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
The SDK seed run failed with:
add_member_roledid a plainINSERT, so granting a role a member already holds raised a UNIQUE-constraint conflict (mapped to a 409). Re-running the seed (or any repeated grant) blew up instead of being a no-op.Fix
INSERT ... ON CONFLICT(user_id, role_id) DO NOTHING— assigning a held role is now an idempotent success (the desired end state already holds), matching the existingadd_thread_followerbehavior.Test
add_member_role_is_idempotent: double-assign succeeds and does not duplicate the membership. Full server suite (129) +clippy -D warningsgreen.Assigning a role a member already holds raised a UNIQUE-constraint error mapped to a 409, which broke re-runnable seeding: assigning role restricted to charlie API error (409): UNIQUE constraint failed: member_roles.user_id, member_roles.role_id Use `INSERT ... ON CONFLICT(user_id, role_id) DO NOTHING` so a repeated grant is a no-op success (the desired end state already holds), matching the existing `add_thread_follower` pattern. Adds a storage regression test asserting a double-assign succeeds without duplicating the membership. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>