Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -78,7 +78,11 @@ final class GutenbergMediaPickerHelper: NSObject {
assert(Thread.isMainThread, "mapMediaIdsToMedia should only be called on the main thread")
let context = ContextManager.shared.mainContext
let request = NSFetchRequest<NSManagedObject>(entityName: "Media")
request.predicate = NSPredicate(format: "mediaID IN %@", mediaIds.map { NSNumber(value: $0) })
request.predicate = NSPredicate(
format: "blog == %@ AND mediaID IN %@",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@crazytonyli question about the blog == %@ constraint this PR added to mapMediaIdsToMedia: Claude flagged it while working on a follow-up in #25866 and I'm not sure whether it's a real problem or not. Below is a summary. WDYT?

The fetch runs on ContextManager.shared.mainContext, but the predicate constrains on blog, which is whatever was passed to GutenbergMediaPickerHelper's initializer:

let context = ContextManager.shared.mainContext
let request = NSFetchRequest<NSManagedObject>(entityName: "Media")
request.predicate = NSPredicate(
    format: "blog == %@ AND mediaID IN %@",
    blog,
    mediaIds.map { NSNumber(value: $0) }
)

A Core Data predicate comparing a relationship against a managed object from a different context matches nothing, so if blog ever belongs to a context other than mainContext, the fetch silently returns no rows and the picker opens with no preselection.

Every path I traced passes a mainContext blog, though I didn't audit this exhaustively — so this may well be unreachable by construction. Is it? If GutenbergMediaPickerHelper is only ever handed a mainContext blog by design, this is a non-issue and I'll leave it alone.

I did try fetching on blog.managedObjectContext locally, but backed it out — SiteMediaCollectionViewController's fetched results controller is hardcoded to mainContext and compares selection by object identity, so that just moves the mismatch somewhere worse.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should be okay here. The theory is correct, and we can certainly make the code more robust by not using a Blog instance. But I believe the Blog instance used here is in the main context. It's a convention where the UI related types uses Core Data instance in the main context.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for providing your perspective. Very helpful. 🙇🏻‍♂️

blog,
mediaIds.map { NSNumber(value: $0) }
)

do {
let fetchedMedia = try context.fetch(request) as? [Media] ?? []
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -235,7 +235,7 @@ class PostGBKEditorViewController: UIViewController, GutenbergKit.EditorViewCont
caption: item.caption,
title: item.filename,
alt: item.alt,
metadata: [:]
metadata: metadata
)
}
if let jsonString = convertMediaInfoArrayToJSONString(mediaInfos) {
Expand Down Expand Up @@ -314,8 +314,6 @@ class PostGBKEditorViewController: UIViewController, GutenbergKit.EditorViewCont
mediaType = mediaType | GutenbergMediaType.other.rawValue
case .any:
mediaType = mediaType | GutenbergMediaType.all.rawValue
@unknown default:
fatalError()
}
}

Expand Down