Deleting a comment from the post options sheet on the post detail screen pops the post screen and skips the screen's own delete handling.
postComments.tsx:457 mounts the sheet without an onDelete:
<PostOptionsModal ref={postOptionsModalRef} isVisibleTranslateModal={true} />
_deletePost only delegates when that prop is present (postOptionsModal.tsx:451). Without it, it runs its own mutation and then calls navigation.goBack() at :478, which on the post detail screen navigates away from the post the user was reading.
It also bypasses _handleDeleteComment (postComments.tsx:174), which the screen already defines and passes to CommentsSection for the inline delete button. That handler owns the error extraction and the deleted-key cache handling, so the sheet path and the button path behave differently for the same action.
This predates #3405; that PR fixed the same gap for the five list surfaces by passing onDelete, and this is the remaining consumer.
Scope
postComments.tsx: pass onDelete forwarding to the existing _handleDeleteComment, with the same arguments the inline button uses.
postOptionsModal.tsx: make the fallback safe rather than relying on every consumer remembering. navigation.goBack() only makes sense when the deleted content is the screen, which is true for a root post and false for a comment in a list. Gate it so a future consumer that forgets onDelete cannot pop the wrong screen.
The second half is the important one: the existing comment on _deletePost already warns about this for waves, and it was still missed twice when adding consumers.
Deleting a comment from the post options sheet on the post detail screen pops the post screen and skips the screen's own delete handling.
postComments.tsx:457mounts the sheet without anonDelete:_deletePostonly delegates when that prop is present (postOptionsModal.tsx:451). Without it, it runs its own mutation and then callsnavigation.goBack()at:478, which on the post detail screen navigates away from the post the user was reading.It also bypasses
_handleDeleteComment(postComments.tsx:174), which the screen already defines and passes toCommentsSectionfor the inline delete button. That handler owns the error extraction and the deleted-key cache handling, so the sheet path and the button path behave differently for the same action.This predates #3405; that PR fixed the same gap for the five list surfaces by passing
onDelete, and this is the remaining consumer.Scope
postComments.tsx: passonDeleteforwarding to the existing_handleDeleteComment, with the same arguments the inline button uses.postOptionsModal.tsx: make the fallback safe rather than relying on every consumer remembering.navigation.goBack()only makes sense when the deleted content is the screen, which is true for a root post and false for a comment in a list. Gate it so a future consumer that forgetsonDeletecannot pop the wrong screen.The second half is the important one: the existing comment on
_deletePostalready warns about this for waves, and it was still missed twice when adding consumers.