fix: dispatch original entity id in DeletedEventDTO, not a post-flush getId()#575
Conversation
… getId() Doctrine nulls an entity's identifier field via reflection after a hard delete is flushed (UnitOfWork::executeDeletions). DeletedEventDTO::fromEntity() was being called after the owning transaction closed, so it read that stale, zeroed id and dispatched 'id' => 0 in the domain event payload. Added DeletedEventDTO::fromId() and switched the affected dispatch call sites to build the DTO from the id captured before removal: - SummitSponsorshipService::removeSponsorship / removeAddOn - SummitSponsorService::deleteSponsor - SummitMediaFileTypeService::delete Also applied the same fromId() call in SummitService::deleteSummit for consistency, though that path only flips a soft-delete flag (no em->remove()), so it never actually reproduced the zeroed-id bug. Added regression tests for all four dispatch paths, verified against the pre-fix code to confirm they fail with the original id => 0 defect (SummitService's stays green either way, per the note above).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (9)
📝 WalkthroughWalkthroughDeletion domain events now construct ChangesDeletion event payloads
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
|
📘 OpenAPI / Swagger preview ➡️ https://OpenStackweb.github.io/summit-api/openapi/pr-575/ This page is automatically updated on each push to this PR. |
… getId() (#575) Doctrine nulls an entity's identifier field via reflection after a hard delete is flushed (UnitOfWork::executeDeletions). DeletedEventDTO::fromEntity() was being called after the owning transaction closed, so it read that stale, zeroed id and dispatched 'id' => 0 in the domain event payload. Added DeletedEventDTO::fromId() and switched the affected dispatch call sites to build the DTO from the id captured before removal: - SummitSponsorshipService::removeSponsorship / removeAddOn - SummitSponsorService::deleteSponsor - SummitMediaFileTypeService::delete Also applied the same fromId() call in SummitService::deleteSummit for consistency, though that path only flips a soft-delete flag (no em->remove()), so it never actually reproduced the zeroed-id bug. Added regression tests for all four dispatch paths, verified against the pre-fix code to confirm they fail with the original id => 0 defect (SummitService's stays green either way, per the note above).
ref: https://app.clickup.com/t/9014802374/86bb35agx
Doctrine nulls an entity's identifier field via reflection after a hard delete is flushed (UnitOfWork::executeDeletions). DeletedEventDTO::fromEntity() was being called after the owning transaction closed, so it read that stale, zeroed id and dispatched 'id' => 0 in the domain event payload.
Added DeletedEventDTO::fromId() and switched the affected dispatch call sites to build the DTO from the id captured before removal:
Also applied the same fromId() call in SummitService::deleteSummit for consistency, though that path only flips a soft-delete flag (no em->remove()), so it never actually reproduced the zeroed-id bug.
Added regression tests for all four dispatch paths, verified against the pre-fix code to confirm they fail with the original id => 0 defect (SummitService's stays green either way, per the note above).
Summary by CodeRabbit
Bug Fixes
Tests