SwiftData crash when setting child Model to parent

I've had a couple SwiftData crashes in production I can’t figure out. Both times the crash happened when setting a child Model to a parent Model. The child should already be inserted in the context before setting on the parent. But a crash still happens at CoreData: _PFManagedObject_coerceValueForKeyWithDescription. The child does have some Codable properties, but they’re just a couple enum. This isn’t a super common crash either. I can’t seem to reproduce. Any ideas?

Simplified models:

@Model
final class Note {
    @Relationship(deleteRule: .nullify, inverse: \CoffeeBag.notes)
    var coffeeBag: CoffeeBag?
}

@Model
final class CoffeeBag {
    var notes: [Note]? = []
}

And the crash stack trace:

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: SIGNAL 6 Abort trap: 6
Terminating Process: MyApp [19953]

Triggered by Thread:  0

Last Exception Backtrace:
0   CoreFoundation                	0x1a2bbe678 __exceptionPreprocess + 164 (NSException.m:249)
1   libobjc.A.dylib               	0x19ae63c80 objc_exception_throw + 60 (objc-exception.mm:356)
2   CoreData                      	0x1aad117a8 _PFManagedObject_coerceValueForKeyWithDescription + 1576 (NSManagedObject.m:0)
3   CoreData                      	0x1aad110e8 _sharedIMPL_setvfk_core + 180 (NSManagedObject_Accessors.m:1491)
4   SwiftData                     	0x23d9359c8 static _DefaultBackingData.setRelationship(value:key:managedObject:) + 360 (BackingData.swift:364)
5   SwiftData                     	0x23d9388fc closure #1 in static _DefaultBackingData.setValue(key:managedObject:newValue:) + 256 (BackingData.swift:215)
6   SwiftData                     	0x23d8d6e4c thunk for @callee_guaranteed () -> () + 28 (<compiler-generated>:0)
7   SwiftData                     	0x23d8d6e74 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0)
8   CoreData                      	0x1aad087c4 developerSubmittedBlockToNSManagedObjectContextPerform + 156 (NSManagedObjectContext.m:3983)
9   CoreData                      	0x1aad08698 -[NSManagedObjectContext performBlockAndWait:] + 208 (NSManagedObjectContext.m:4094)
10  SwiftData                     	0x23d933758 static _DefaultBackingData.setValue(key:managedObject:newValue:) + 360 (BackingData.swift:211)
11  SwiftData                     	0x23d9383b0 _DefaultBackingData.setValue<A>(forKey:to:) + 232 (BackingData.swift:174)
12  SwiftData                     	0x23d93b328 protocol witness for BackingData.setValue<A>(forKey:to:) in conformance _DefaultBackingData<A> + 24 (<compiler-generated>:0)
13  SwiftData                     	0x23d8f32dc PersistentModel.setValue<A>(forKey:to:) + 288 (PersistentModel.swift:102)
14  MyApp                       	0x100f166d4 closure #1 in MyAppSchemaV6.Note.coffeeBag.setter + 132 (@__swiftmacro_7MyApp0aB8SchemaV6O4NoteC9coffeeBag18_PersistedPropertyfMa_.swift:15)
15  MyApp                       	0x100f22864 partial apply for closure #1 in MyAppSchemaV6.Note.coffeeBag.setter + 16 (<compiler-generated>:0)
16  libswiftObservation.dylib     	0x247ff21b8 ObservationRegistrar.withMutation<A, B, C>(of:keyPath:_:) + 100 (ObservationRegistrar.swift:365)
17  MyApp                       	0x100f21c28 MyAppSchemaV6.Note.coffeeBag.setter + 172 (@__swiftmacro_7MyApp0aB8SchemaV6O4NoteC9coffeeBag18_PersistedPropertyfMa_.swift:14)
18  MyApp                       	0x100f21c28 closure #1 in closure #1 in closure #4 in BrewSummaryView.body.getter + 1076 (BrewSummaryView.swift:116)
19  SwiftUI                       	0x1a81b77b0 ButtonAction.callAsFunction() + 260 (Button.swift:598)
// the rest is trimmed off to fit...

On One-to-Many relationships, Apple's sample code typically shows the @Relationship macro on the One side. Although it's supposed to work either way, I'll bet it was tested more thoroughly on that direction. And I've certainly found the @Relationship macro to have some fragile quirks.

@Bardi In my case I've already inserted both models into the context. The crash reference in that thread is a well known one to me already.

did you figure this out

SwiftData crash when setting child Model to parent
 
 
Q