perf: use after_create_commit for comment relaying

[MatrixNeoKozak]

Optimizes the Comment model by changing after_commit to after_create_commit. This ensures the CommentRelayJob is only triggered upon the creation of a new comment, avoiding unnecessary broadcast operations when existing comments are updated. This improves system efficiency and reduces unnecessary WebSocket traffic. Closes #0

Summary by CodeRabbit

• Chores
  • Optimized comment relay processing timing to improve efficiency and accuracy.

[github-actions]

🚀 Quick Review App Commands

Welcome! Here are the commands you can use in this PR:
They require the repository to have cpflow review apps configured, including the CPLN_TOKEN_STAGING secret.

+review-app-deploy

Deploy your PR branch for testing.

+review-app-delete

Remove the review app when done.

+review-app-help

Show detailed instructions, environment setup, and configuration options.

Comment +review-app-help for full setup details.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d1b2251d-f195-4eaa-8238-2f56c29f44ab

📥 Commits

Reviewing files that changed from the base of the PR and between 9bd3cbd and 2a867db.

📒 Files selected for processing (1)

• app/models/comment.rb

---

Walkthrough

The Comment model's background job callback is changed from after_commit to after_create_commit, restricting CommentRelayJob enqueuing to comment creation only rather than all commit operations.

Changes

Comment Relay Job Trigger

Layer / File(s)	Summary
Comment create callback app/models/comment.rb	CommentRelayJob.perform_later(self) callback narrowed from after_commit to after_create_commit, limiting job enqueuing to comment creation commits only.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'perf: use after_create_commit for comment relaying' directly describes the main change: replacing after_commit with after_create_commit for the comment relay callback to improve performance.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[greptile-apps]

Greptile Summary

This PR swaps after_commit for after_create_commit on the Comment model so that CommentRelayJob (which broadcasts comments over ActionCable) is only enqueued when a comment is first created, not on every subsequent commit.

• Behavioral regression on updates: CommentsController exposes update and edit actions, meaning comments can be edited. With after_commit, edits triggered a broadcast so all WebSocket subscribers would see the new text immediately. With after_create_commit, comment edits and destroys will never enqueue the job, leaving connected clients with stale comment data.
• Orphaned guard in CommentRelayJob: The unless comment.destroyed? guard was originally needed because after_commit also fired on destroy. That scenario can no longer occur with after_create_commit, so the guard becomes effectively dead code.

Confidence Score: 3/5

The change silently drops ActionCable broadcasts for comment edits and deletes, leaving connected clients with stale data; merging as-is would regress real-time update behavior.

Switching to after_create_commit removes broadcast coverage for update and destroy operations that the controller actively exposes. WebSocket subscribers will no longer receive notifications when a comment is edited or deleted, which is a present behavioral regression rather than a theoretical one.

app/models/comment.rb — the callback change and its interaction with the existing update/destroy actions needs a second look before merging.

Important Files Changed

Filename	Overview
app/models/comment.rb	Changed after_commit to after_create_commit, which drops ActionCable broadcasting for comment updates and destroys — a real behavioral change given the app has update/destroy actions.

Sequence Diagram

sequenceDiagram
    participant Client
    participant CommentsController
    participant Comment
    participant CommentRelayJob
    participant ActionCable

    Note over Comment,ActionCable: BEFORE (after_commit — fires on create, update, destroy)
    Client->>CommentsController: POST /comments (create)
    CommentsController->>Comment: save
    Comment->>CommentRelayJob: perform_later(self) [after create commit]
    CommentRelayJob->>ActionCable: broadcast "comments"

    Client->>CommentsController: PATCH /comments/:id (update)
    CommentsController->>Comment: update(...)
    Comment->>CommentRelayJob: perform_later(self) [after update commit]
    CommentRelayJob->>ActionCable: broadcast "comments"

    Note over Comment,ActionCable: AFTER (after_create_commit — fires on create only)
    Client->>CommentsController: POST /comments (create)
    CommentsController->>Comment: save
    Comment->>CommentRelayJob: perform_later(self) [after create commit]
    CommentRelayJob->>ActionCable: broadcast "comments"

    Client->>CommentsController: PATCH /comments/:id (update)
    CommentsController->>Comment: update(...)
    Note over Comment: No callback fires — subscribers not notified

Loading

_{Reviews (1): Last reviewed commit: "perf: use after_create_commit for commen..." | Re-trigger Greptile}

[greptile-apps]

Broadcasting silently dropped for updates and destroys

after_create_commit only fires after an INSERT, so comment edits and deletes no longer enqueue CommentRelayJob. The app exposes both update and destroy actions via CommentsController, so any client subscribed to the "comments" ActionCable channel will continue to see stale data after a comment is edited or deleted. If real-time updates on create are the only required behaviour this is fine, but the PR description frames it purely as a performance improvement, which obscures the functional trade-off.