Allow users to use the /setinvoice command on order in status "WAITING_BUYER_INVOICE"

[Luquitasjeffrey]

Fixes #718

Summary by CodeRabbit

• Bug Fixes
  • Invoice confirmation now recognizes both paid-hold and waiting-buyer orders, improving matching for invoice-related prompts.
  • Invoice action handling now verifies the order exists and routes processing based on order status so invoices are handled correctly for different scenarios.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 299895bd-d017-4967-95df-e74a0dc2959e

📥 Commits

Reviewing files that changed from the base of the PR and between 435b7e2 and 70f1884.

📒 Files selected for processing (1)

• bot/start.ts

🚧 Files skipped from review as they are similar to previous changes (1)

• bot/start.ts

---

Walkthrough

Updated /setinvoice confirmation-order lookup to include orders with status PAID_HOLD_INVOICE or WAITING_BUYER_INVOICE. The action handler now loads the order by _id, returns early if not found, and calls addInvoice for WAITING_BUYER_INVOICE or addInvoicePHI otherwise.

Changes

Cohort / File(s)	Summary
Invoice Action Handler bot/start.ts	Expanded status match to include WAITING_BUYER_INVOICE. Refactored setinvoice_<orderId> handler to load order by _id, early-return if missing, and route to addInvoice for WAITING_BUYER_INVOICE or addInvoicePHI for other matched statuses.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Suggested reviewers

• mostronatorcoder

Poem

🐰 I found the order in the night,
checking statuses left and right.
If waiting, I add one way,
if held, another I relay.
A small hop, and all is bright.

🚥 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 accurately describes the main change: enabling /setinvoice command for orders in WAITING_BUYER_INVOICE status.
Linked Issues check	✅ Passed	The PR successfully implements the coding requirement from issue #718 by enabling /setinvoice on WAITING_BUYER_INVOICE status orders, allowing users to exit wizard mode and complete trades.
Out of Scope Changes check	✅ Passed	All changes are directly related to issue #718: updating /setinvoice confirmation lookup, routing logic, and removing duplicate deleteMessage calls as noted in the objectives.
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

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch issue718

---

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]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

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

Inline comments:
In `@bot/start.ts`:
- Around line 895-903: Remove the redundant ctx.deleteMessage() call in the
action handler and make the status routing explicit: instead of calling
addInvoicePHI in the else branch, check if order.status === 'PAID_HOLD_INVOICE'
and call addInvoicePHI(ctx, bot, ctx.match[1]) only in that case; for any other
status do not call either handler (or handle explicitly if needed). Update the
handler around the Order lookup (the block that calls addInvoice and
addInvoicePHI) to remove the standalone ctx.deleteMessage() and rely on the
deleteMessage calls inside addInvoice and addInvoicePHI, and replace the else
with an explicit status comparison to 'PAID_HOLD_INVOICE'.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 15006388-d1cc-4920-90b9-1b1ece2a9ae4

📥 Commits

Reviewing files that changed from the base of the PR and between 66e0004 and 435b7e2.

📒 Files selected for processing (1)

• bot/start.ts

[mostronatorcoder]

Approved, the change is aligned with issue #718 and the /setinvoice action already routes WAITING_BUYER_INVOICE through addInvoice, so the flow looks consistent. The only thing still missing for me is test coverage for this state transition.

A simple test idea would be to cover askForConfirmation(..., '/setinvoice') or the command handler and assert that orders in both PAID_HOLD_INVOICE and WAITING_BUYER_INVOICE are offered to the buyer. For example, create a buyer fixture, seed one order in WAITING_BUYER_INVOICE, run the /setinvoice command, and assert that the confirmation buttons include that order id. That would protect this exact regression in the future.