Summary
After upgrading EntityFramework.Exceptions, DbUpdateException no longer correctly exposes only the failed entries. In the previous version, it was possible to retrieve the specific entities that caused the failure. However, this behavior is not observed in the current version.
Expected Behavior
DbUpdateException should provide access to only the failed entity entries (e.g., via Entries or equivalent), allowing identification of which records caused the failure.
Actual Behavior
When a batch operation (AddRange / UpdateRange) fails:
- The entire batch throws an exception
- ex.Entries returns all entities in the batch, instead of only the failed ones
- There is no straightforward way to identify which specific entity/entities caused the failure
catch (DbUpdateException ex) { var entries = ex.Entries; // Expected: only failed entries // Actual: returns all entities in the batch }
Additional Context
In earlier versions, failed entries were accessible from the exception, which significantly helped in handling batch failures and implementing retry logic.
This appears to be either a regression or a behavioral change in the current version. Clarification on whether this is intentional, and guidance on the recommended approach to identify failed entities, would be helpful.
Summary
After upgrading EntityFramework.Exceptions, DbUpdateException no longer correctly exposes only the failed entries. In the previous version, it was possible to retrieve the specific entities that caused the failure. However, this behavior is not observed in the current version.
Expected Behavior
DbUpdateException should provide access to only the failed entity entries (e.g., via Entries or equivalent), allowing identification of which records caused the failure.
Actual Behavior
When a batch operation (AddRange / UpdateRange) fails:
catch (DbUpdateException ex) { var entries = ex.Entries; // Expected: only failed entries // Actual: returns all entities in the batch }Additional Context
In earlier versions, failed entries were accessible from the exception, which significantly helped in handling batch failures and implementing retry logic.
This appears to be either a regression or a behavioral change in the current version. Clarification on whether this is intentional, and guidance on the recommended approach to identify failed entities, would be helpful.