Guard against nil reply in createReplyForComment callback

[jkmassel]

Summary

• createReplyForComment's completion is annotated non-null, but its implementation can hand back nil — the reply is re-resolved on the main context via existingObjectWithID:error:, which returns nil when the just-created optimistic comment can't be resolved again (a rare Core Data race).
• Annotate the callback _Nullable so the type tells the truth, and guard the single caller so a nil reply reports a clean failure instead of silently forwarding nil to uploadComment.

Root Cause

The completion resolves its value via [self.coreDataStack.mainContext existingObjectWithID:replyID error:nil] (CommentService.m:119), which returns nil if the optimistic comment can't be re-resolved. The header (CommentService.h) sits inside NS_ASSUME_NONNULL_BEGIN, so the unannotated Comment * has imported into Swift as a non-optional Comment since the method was refactored into this shape in 2023 (63aa79dedd). Callers therefore couldn't guard the value even though the implementation can produce nil.

It's been harmless so far because the one caller only forwards reply to uploadComment(reply, …) — Objective-C, where messaging nil is a safe no-op. It has never been dereferenced in Swift.

Fix

• _Nullable on the callback in CommentService.h / .m, so it imports into Swift as Comment?.
• guard let reply in CommentDetailViewController.createReply — a nil reply resumes the continuation with URLError(.unknown) (the error the method's existing failure branch already uses) rather than messaging nil. uploadComment takes a non-null Comment, so the guard is required once reply is optional.
• Adding the guard turns that completion into a multi-statement closure, which stops withUnsafeThrowingContinuation's T from being inferred from the nested continuation.resume(). Pin it explicitly with UnsafeContinuation<Void, Error> — the same idiom already used in BlogService+Settings and JetpackConnectionViewModel.

Test plan

• Builds — the guard let only compiles once _Nullable makes reply import as Comment?, so a green build confirms the annotation and the guard are consistent.
• Replying to a comment from the comment detail / a notification still posts normally.

There are no existing tests over createReplyForComment (a thin Core Data + callback wrapper), so this contract fix doesn't add one.

Related

Splits a correctness fix out of #25945, which adds the first Swift dereference of this callback (TaggedManagedObjectID(reply)) and would otherwise turn this latent inaccuracy into a reachable crash. Landing this first lets #25945 rebase onto an already-_Nullable callback with the guard in place.

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	34118
	Version	PR #25964
	Bundle ID	org.wordpress.alpha
	Commit	e5d2397
	Installation URL	1figo67q5i8og

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	34118
	Version	PR #25964
	Bundle ID	com.jetpack.alpha
	Commit	e5d2397
	Installation URL	03tqabs0sua30

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.