feat: search command responds to repliedTo or invoker msg

[lorenzocorallo]

closes #57

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3229ad74-19f7-4a0a-8b4f-0718feec60b0

📥 Commits

Reviewing files that changed from the base of the PR and between de278da and 354986f.

📒 Files selected for processing (1)

• src/commands/search.ts

---

Walkthrough

The search command handler signature now accepts a repliedTo parameter and the command includes reply: "optional". Replies (both no-results and success) set reply_parameters.message_id to repliedTo.message_id when present, otherwise fall back to context.msgId.

Changes

Cohort / File(s)	Summary
Search command src/commands/search.ts	Handler signature changed to async ({ context, args, repliedTo }). Added reply: "optional" to the command. Reply logic updated to include reply_parameters.message_id using repliedTo.message_id if available, otherwise context.msgId, for both no-results and success replies.

Possibly related PRs

• feat: search command responds to repliedTo or invoker msg #71: Modifies the same src/commands/search.ts handler to accept repliedTo and set reply_parameters.message_id for no-result and success replies — directly related.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically summarizes the main change: enabling the search command to respond to replied-to or invoker messages, which matches the primary objective.
Linked Issues check	✅ Passed	The code changes successfully implement the requirement from issue #57 by adding repliedTo parameter handling to the search command handler and using it to set reply_parameters.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing the linked issue requirement of making the search command respond to repliedTo messages; no extraneous modifications detected.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

📝 Coding Plan

• Generate coding plan for human review comments

---

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.}

[coderabbitai]

🧹 Nitpick comments (1)

src/commands/search.ts (1)

24-24: Deduplicate reply target resolution to reduce drift risk.

Line 24 and Line 53 repeat the same fallback expression. Consider computing it once and reusing it in both replies.

♻️ Proposed refactor

 handler: async ({ context, args, repliedTo }) => {
+  const replyToMessageId = repliedTo?.message_id ?? context.msgId
   const res = await api.tg.groups.search.query({ query: args.query, limit: LIMIT })
   if (res.count === 0) {
     await context.reply(
       fmt(({ n, b, i }) => [b`🔎 Group Search`, n`${i`Query:`} ${b`${args.query}`}`, b`❌ No results`], {
         sep: "\n",
       }),
-      { reply_parameters: { message_id: repliedTo ? repliedTo.message_id : context.msgId } }
+      { reply_parameters: { message_id: replyToMessageId } }
     )
     return
   }
@@
   await context.reply(reply, {
     link_preview_options: { is_disabled: true },
     reply_markup: inlineKeyboard,
-    reply_parameters: { message_id: repliedTo ? repliedTo.message_id : context.msgId },
+    reply_parameters: { message_id: replyToMessageId },
   })
 },

Also applies to: 53-53

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/search.ts` at line 24, The reply target is computed twice using
the fallback expression repliedTo ? repliedTo.message_id : context.msgId;
compute it once (e.g., const targetMessageId = repliedTo?.message_id ??
context.msgId) near the start of the handler and reuse targetMessageId in both
reply payloads instead of repeating the expression to avoid drift; update the
two locations that set reply_parameters.message_id to use targetMessageId
(referencing repliedTo and context.msgId for the original values).

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@src/commands/search.ts`:
- Line 24: The reply target is computed twice using the fallback expression
repliedTo ? repliedTo.message_id : context.msgId; compute it once (e.g., const
targetMessageId = repliedTo?.message_id ?? context.msgId) near the start of the
handler and reuse targetMessageId in both reply payloads instead of repeating
the expression to avoid drift; update the two locations that set
reply_parameters.message_id to use targetMessageId (referencing repliedTo and
context.msgId for the original values).

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8c7eeb81-fe5b-4832-baf7-f1aeeb4592de

📥 Commits

Reviewing files that changed from the base of the PR and between 4cbfbfb and de278da.

📒 Files selected for processing (1)

• src/commands/search.ts