Skip to content

Comments

🐛 Fixed reply form showing parent comment author's details#2

Open
tomerqodo wants to merge 2 commits intocoderabbit_full_base__fixed_reply_form_showing_parent_comment_authors_details_pr2from
coderabbit_full_head__fixed_reply_form_showing_parent_comment_authors_details_pr2
Open

🐛 Fixed reply form showing parent comment author's details#2
tomerqodo wants to merge 2 commits intocoderabbit_full_base__fixed_reply_form_showing_parent_comment_authors_details_pr2from
coderabbit_full_head__fixed_reply_form_showing_parent_comment_authors_details_pr2

Conversation

@tomerqodo
Copy link

@tomerqodo tomerqodo commented Jan 29, 2026

Benchmark PR from agentic-review-benchmarks#2

Summary by CodeRabbit

  • Bug Fixes
    • Fixed reply forms incorrectly inheriting parent comment author's expertise; now displays the current user's own expertise status.
    • Improved handling of member name fallbacks in reply forms to prevent incorrect name attribution.
    • Enhanced reply linking to ensure replies are correctly associated with their parent comments.

✏️ Tip: You can customize this high-level summary in your review settings.

rob-ghost and others added 2 commits January 25, 2026 11:56
ref https://linear.app/ghost/issue/BER-3212

When a user opened a reply form, the form header was showing the parent
comment author's name and expertise instead of the current user's data.
This happened because the code used a fallback pattern that pulled from
the comment being replied to when the current member had no value set.
@coderabbitai
Copy link

coderabbitai bot commented Jan 29, 2026

📝 Walkthrough

Walkthrough

The changes refactor the comment form system by eliminating the comment prop from FormWrapperProps and FormWrapper, instead deriving member data directly from the member object. The reply form now targets the parent comment by its ID. Two E2E tests were added to verify reply form behavior regarding member expertise and name inheritance.

Changes

Cohort / File(s) Summary
Form component refactoring
apps/comments-ui/src/components/content/forms/form.tsx, apps/comments-ui/src/components/content/forms/reply-form.tsx
Removed comment prop from FormWrapperProps and FormWrapper component. Updated member data extraction to use only member?.name and member?.expertise (no fallback to comment member data). Modified reply target to use parent.id instead of openForm.in_reply_to_id. Updated effect dependencies to reflect new data sources.
E2E test coverage
apps/comments-ui/test/e2e/actions.test.ts
Added two new end-to-end tests verifying that reply form shows logged-in member's expertise (not inherited from parent) and correctly handles missing member names without inheriting parent author name.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 Hopping through forms with care and grace,
We've removed the comment's extra space,
Now member data flows so clean,
The simplest form you've ever seen!
With tests that verify what's true,
Our changes are tested through and through!

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title directly describes the main bug fix: preventing the reply form from incorrectly displaying parent comment author details instead of the logged-in user's information.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🤖 Fix all issues with AI agents
In `@apps/comments-ui/src/components/content/forms/form.tsx`:
- Around line 263-265: The editability check currently uses member?.expertise in
editor.setEditable but focusEditor only checks memberName, causing the editor to
become read-only for users who have a name but no expertise; update the gating
in the effect that calls editor.setEditable to match the name-based requirement
used by focusEditor (e.g., use memberName or member?.name and progress !==
'sending'), or otherwise update focusEditor to enforce the same expertise
requirement—ensure you modify the same effect surrounding editor.setEditable and
reference the member/memberName and progress values consistently.
- Around line 308-314: When computing openStyles in the FormWrapper (inside
form.tsx) you must guard access to openForm.in_reply_to_snippet because openForm
is optional in FormWrapperProps and may be undefined when isOpen is true; change
the access to use optional chaining (e.g., compute isReplyToReply using
openForm?.in_reply_to_snippet) or add an explicit null check on openForm before
reading in_reply_to_snippet so the isReplyToReply/ openStyles logic never reads
a property from undefined.

Comment on lines 263 to +265
// Disable editing if the member doesn't have a name or when we are submitting the form
editor.setEditable(!!memberName && progress !== 'sending');
}, [editor, memberName, progress]);
editor.setEditable(!!member?.expertise && progress !== 'sending');
}, [editor, member, progress]);
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

Editability gate now blocks users with name but no expertise.

focusEditor only checks memberName, but setEditable now requires member?.expertise, which can leave the editor read‑only with no prompt. If expertise isn’t intended to be mandatory, this is a regression.

🔧 Suggested fix (align gating with name requirement)
-        // Disable editing if the member doesn't have a name or when we are submitting the form
-        editor.setEditable(!!member?.expertise && progress !== 'sending');
-    }, [editor, member, progress]);
+        // Disable editing if the member doesn't have a name or when we are submitting the form
+        editor.setEditable(!!memberName && progress !== 'sending');
+    }, [editor, memberName, progress]);
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
// Disable editing if the member doesn't have a name or when we are submitting the form
editor.setEditable(!!memberName && progress !== 'sending');
}, [editor, memberName, progress]);
editor.setEditable(!!member?.expertise && progress !== 'sending');
}, [editor, member, progress]);
// Disable editing if the member doesn't have a name or when we are submitting the form
editor.setEditable(!!memberName && progress !== 'sending');
}, [editor, memberName, progress]);
🤖 Prompt for AI Agents
In `@apps/comments-ui/src/components/content/forms/form.tsx` around lines 263 -
265, The editability check currently uses member?.expertise in
editor.setEditable but focusEditor only checks memberName, causing the editor to
become read-only for users who have a name but no expertise; update the gating
in the effect that calls editor.setEditable to match the name-based requirement
used by focusEditor (e.g., use memberName or member?.name and progress !==
'sending'), or otherwise update focusEditor to enforce the same expertise
requirement—ensure you modify the same effect surrounding editor.setEditable and
reference the member/memberName and progress values consistently.

Comment on lines +308 to 314
const memberName = member?.name;
const memberExpertise = member?.expertise;

let openStyles = '';
if (isOpen) {
const isReplyToReply = !!openForm?.in_reply_to_snippet;
const isReplyToReply = !!openForm.in_reply_to_snippet;
openStyles = isReplyToReply ? 'pl-[1px] pt-[68px] sm:pl-[44px] sm:pt-[56px]' : 'pl-[1px] pt-[48px] sm:pl-[44px] sm:pt-[40px]';
Copy link

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cd apps/comments-ui && find . -name "form.tsx" -type f

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 134


🏁 Script executed:

# First, let's look at the FormWrapper component itself
rg -n "FormWrapper" --type=tsx -l

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 122


🏁 Script executed:

# Search for FormWrapper usages as suggested in the review
rg -n "FormWrapper" --type=tsx -A 2 -B 2

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 122


🏁 Script executed:

# Try with ts file type
rg -n "FormWrapper" --type=ts -A 2 -B 2

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 4108


🏁 Script executed:

# Also try with extension pattern
rg -n "FormWrapper" --glob="*.tsx" -A 2 -B 2

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 4108


🏁 Script executed:

# Look at the form.tsx file to understand the component
head -100 apps/comments-ui/src/components/content/forms/form.tsx

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 3462


🏁 Script executed:

# Check the FormWrapperProps type definition more carefully
sed -n '291,297p' apps/comments-ui/src/components/content/forms/form.tsx

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 256


🏁 Script executed:

# Now let's look at the problematic code section around lines 308-314
sed -n '305,320p' apps/comments-ui/src/components/content/forms/form.tsx

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 618


🏁 Script executed:

# Check main-form.tsx to see when isOpen can be true
cat apps/comments-ui/src/components/content/forms/main-form.tsx | head -110

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 3870


🏁 Script executed:

# Check if there are any other usages of FormWrapper we might have missed
rg -n "FormWrapper" --glob="*.tsx" -B 1 -A 1

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 2792


🏁 Script executed:

# Verify what openForm is (the type)
rg -n "OpenCommentForm" --glob="*.ts" --glob="*.tsx" -A 3 | head -50

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 3910


🏁 Script executed:

# Let me get the full OpenCommentForm type definition
rg -n "export type OpenCommentForm" --glob="*.ts" -A 10

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 768


🏁 Script executed:

# Let me check the full FormWrapper implementation to be thorough
sed -n '299,330p' apps/comments-ui/src/components/content/forms/form.tsx

Repository: agentic-review-benchmarks/Ghost-combined-coderabbit

Length of output: 1051


Use optional chaining to safely access openForm.in_reply_to_snippet when isOpen is true.

openForm is optional in FormWrapperProps, but in main-form.tsx the component is called with isOpen potentially true without providing openForm. This will cause a runtime error when trying to access openForm.in_reply_to_snippet at line 313.

Fix
-        const isReplyToReply = !!openForm.in_reply_to_snippet;
+        const isReplyToReply = !!openForm?.in_reply_to_snippet;
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
const memberName = member?.name;
const memberExpertise = member?.expertise;
let openStyles = '';
if (isOpen) {
const isReplyToReply = !!openForm?.in_reply_to_snippet;
const isReplyToReply = !!openForm.in_reply_to_snippet;
openStyles = isReplyToReply ? 'pl-[1px] pt-[68px] sm:pl-[44px] sm:pt-[56px]' : 'pl-[1px] pt-[48px] sm:pl-[44px] sm:pt-[40px]';
const memberName = member?.name;
const memberExpertise = member?.expertise;
let openStyles = '';
if (isOpen) {
const isReplyToReply = !!openForm?.in_reply_to_snippet;
openStyles = isReplyToReply ? 'pl-[1px] pt-[68px] sm:pl-[44px] sm:pt-[56px]' : 'pl-[1px] pt-[48px] sm:pl-[44px] sm:pt-[40px]';
🤖 Prompt for AI Agents
In `@apps/comments-ui/src/components/content/forms/form.tsx` around lines 308 -
314, When computing openStyles in the FormWrapper (inside form.tsx) you must
guard access to openForm.in_reply_to_snippet because openForm is optional in
FormWrapperProps and may be undefined when isOpen is true; change the access to
use optional chaining (e.g., compute isReplyToReply using
openForm?.in_reply_to_snippet) or add an explicit null check on openForm before
reading in_reply_to_snippet so the isReplyToReply/ openStyles logic never reads
a property from undefined.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants