Found while following the skill on a Jmix 3.0.0 project.
Problem: silent — no mention of ordering dataManager.remove calls to respect FK direction.
Task
Extending an existing @AfterEach in a seeding test to also delete a newly-seeded child entity (OrderLine) that references Order, which in turn now carries FK references to Customer/Product.
Where
"Cleanup Audit" bullet "Every created persistent record is removed in @AfterEach, using the same authentication level needed for deletion."
What happened
The existing @AfterEach was extended by prepending a remove of the new child rows but leaving the existing order (Customer, Product, Order) as-is. That order was accidentally safe before, because earlier tests' Order rows never set the FK references. Once a test seeded rows with those FKs populated, deleting Customer while orders still referenced it threw a foreign-key constraint violation in @AfterEach itself, failing all tests in the class (not just the new ones) because JUnit reports a teardown exception against the test that triggered it. It surfaced as a persistence exception at the @AfterEach line rather than a normal assertion failure, so it first read as a seeding bug, not a teardown-ordering bug. Caught by a clean test run.
Suggested fix
Add a bullet to "Cleanup Audit": @AfterEach deletions must run in FK-safe order — child rows (holding a @ManyToOne/@JoinColumn to another cleaned-up entity) before the parents they reference — and re-check this every time a new FK is added to an entity already covered by an existing cleanup block, since a previously-safe order can silently become unsafe.
Found while following the skill on a Jmix 3.0.0 project.
Problem: silent — no mention of ordering
dataManager.removecalls to respect FK direction.Task
Extending an existing
@AfterEachin a seeding test to also delete a newly-seeded child entity (OrderLine) that referencesOrder, which in turn now carries FK references toCustomer/Product.Where
"Cleanup Audit" bullet "Every created persistent record is removed in
@AfterEach, using the same authentication level needed for deletion."What happened
The existing
@AfterEachwas extended by prepending a remove of the new child rows but leaving the existing order (Customer,Product,Order) as-is. That order was accidentally safe before, because earlier tests'Orderrows never set the FK references. Once a test seeded rows with those FKs populated, deletingCustomerwhile orders still referenced it threw a foreign-key constraint violation in@AfterEachitself, failing all tests in the class (not just the new ones) because JUnit reports a teardown exception against the test that triggered it. It surfaced as a persistence exception at the@AfterEachline rather than a normal assertion failure, so it first read as a seeding bug, not a teardown-ordering bug. Caught by a clean test run.Suggested fix
Add a bullet to "Cleanup Audit":
@AfterEachdeletions must run in FK-safe order — child rows (holding a@ManyToOne/@JoinColumnto another cleaned-up entity) before the parents they reference — and re-check this every time a new FK is added to an entity already covered by an existing cleanup block, since a previously-safe order can silently become unsafe.