Bugfix: Distinguish i18n contexts for buyer and seller in cancelShowH…

[Matobi98]

PR: Fix Timeout/Expiry Notifications Language Localization

Overview

This PR fixes a bug where timeout/expiry notifications for sell orders were being sent to both the buyer and the seller in the buyer's configured language. The system now correctly identifies each user's language preference and sends personalized notifications.

Key Changes

Language Localization

Updated cancelShowHoldInvoice in bot/commands.ts to fetch both buyerUser and sellerUser data.

Individual i18n Contexts

Every party now has their own i18n context retrieved via getUserI18nContext().

Targeted Messaging

Outgoing message functions:

• toSellerDidntPayInvoiceMessage
• toBuyerSellerDidntPayInvoiceMessage
• publishBuyOrderMessage
• etc.

Now receive the specific language context for the recipient.

Error Handling

Added an explicit exception if the seller user is not found during the cancellation process to improve reliability.

Summary by CodeRabbit

• Refactor
  • Improved cancellation message handling to ensure sellers and buyers receive appropriately tailored messages during invoice cancellation operations.

[coderabbitai]

Walkthrough

This pull request refactors cancellation logic in bot/commands.ts to implement per-user i18n contexts. The cancelAddInvoice and cancelShowHoldInvoice functions now distinguish between seller and buyer contexts when sending messages, replacing a single unified context with role-specific ones.

Changes

Cohort / File(s)	Summary
Per-user i18n context refactoring bot/commands.ts	Refactored cancelAddInvoice and cancelShowHoldInvoice to introduce sellerUser and buyerUser with computed i18n contexts. Replaced single context usage with role-specific messaging, adjusted log message references, and updated all messaging functions to receive appropriate user contexts.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• hot-fix with cancelation in waitin-payment status #657: Related through cancellation flow modifications affecting cancelShowHoldInvoice invocation timing in the WAITING_PAYMENT state.

Suggested reviewers

• grunch
• mostronatorcoder

Poem

🐰 Whiskers twitching with glee,
Per-user contexts dance so free,
Sellers, buyers both get their say,
No more confusion—hooray, hooray!
Each role's message finds its way. 🎭✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the main change: fixing i18n context distinction for buyer and seller in cancellation flows, which matches the PR's core objective of ensuring each party receives notifications in their own language.
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 unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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/commands.ts`:
- Around line 499-504: The guard that checks order.status !== 'WAITING_PAYMENT'
currently always sends messages.genericErrorMessage(ctx, sellerUser,
i18nCtxSeller) which can DM the wrong person; change it to send the error to the
acting user instead: determine the acting user (the request initiator used
earlier in cancelOrder — e.g., the variable representing the caller) and its
i18n context (from getUserI18nContext), then call
messages.genericErrorMessage(ctx, actingUser, actingI18nCtx) when the status is
invalid, leaving sellerUser/buyerUser untouched for other flows.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 604291ec-9b54-48f6-a7a0-1124aca0716c

📥 Commits

Reviewing files that changed from the base of the PR and between 725a5fa and fd7c7d6.

📒 Files selected for processing (1)

• bot/commands.ts

[mostronatorcoder]

Code Review ✅

Clean fix for the i18n context bug. Each party now receives messages in their own language.

Changes verified

Message	Recipient	Context Used
toSellerDidntPayInvoiceMessage	Seller	i18nCtxSeller ✅
toBuyerSellerDidntPayInvoiceMessage	Buyer	i18nCtxBuyer ✅
successCancelOrderMessage (buyer)	Buyer	i18nCtxBuyer ✅
counterPartyCancelOrderMessage	Seller	i18nCtxSeller ✅
publishBuyOrderMessage	Buyer	i18nCtxBuyer ✅
publishSellOrderMessage	Seller	i18nCtxSeller ✅
toAdminChannelSellerDidntPayInvoiceMessage	Admin (about seller)	i18nCtxSeller ✅

Error handling improvement ✅

Explicit throw new Error when buyer/seller not found — better than silent return.

Code structure ✅

• Both users fetched early, before any logic
• i18n contexts created once, reused throughout
• Variable renamed from user to sellerUser for clarity

CI ✅

All checks passing.

Summary

LGTM. Simple and correct fix.