Conversation
…on sessi…" This reverts commit 87ff37b.
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Review rate limit: 0/1 reviews remaining, refill in 44 minutes and 28 seconds.Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 872f9d591d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if let Err(e) = send_restore_session_response( | ||
| &trade_key, | ||
| &master_key, | ||
| result.restore_orders, | ||
| result.restore_disputes, | ||
| pool.clone(), | ||
| ) |
There was a problem hiding this comment.
Restore AddInvoice resend for failed payments
This revert drops the only restore-session path that re-queues Action::AddInvoice for orders stuck in settled-hold-invoice with failed_payment=true. In the current flow, send_restore_session_response now only sends RestoreData, so if the buyer was offline when the original failure notification was emitted, reconnecting via restore-session will not trigger the invoice re-prompt and that order can remain blocked until manual intervention. Please keep restore-session tied to failed-payment lookup so those buyers reliably receive the retry prompt after reconnect.
Useful? React with 👍 / 👎.
Reverts #721