Repository navigation
developブランチをmainにマージします - #279
Conversation
着信時のポップアップを追加しました
…s-label #270 発着信履歴のステータスの詳細化
…upport Feat/272 outbound inbound support
…ory-display #275 発信履歴の表示バグを修正
Refs #277 Instruction by: @MasanoriSuda Generated by: Codex
feat(ci): add backend codecov workflow
|
Warning Rate limit exceeded
⌛ 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: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (40)
✨ 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. Comment |
|
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f5ce292acc
ℹ️ 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".
| .map(|s| s.elapsed().as_secs().min(i32::MAX as u64) as i32); | ||
| let call_log_id = self.ensure_call_log_id(); | ||
| let caller_number = extract_e164_caller_number(self.from_uri.as_str()); | ||
| let (direction, callee_number) = if self.outbound_mode { |
There was a problem hiding this comment.
Preserve outbound direction when persisting failed calls
send_ingest derives direction solely from the current self.outbound_mode, but outbound failures clear that flag in the B2BUA failure path before ingest is written (handlers/mod.rs in SessionControlIn::B2buaFailed), so failed outbound attempts are persisted as inbound with no callee number. This corrupts call-log direction data and causes outbound failure records to be misclassified in downstream sync/UI flows.
Useful? React with 👍 / 👎.
| } | ||
|
|
||
| try { | ||
| const entry = await addIncomingCallNotification(payload) |
There was a problem hiding this comment.
Enforce idempotency when ingesting incoming-call notifications
This handler always appends a new notification entry with a random UUID and does not deduplicate by call_id/Idempotency-Key, even though the backend worker sends retries with Idempotency-Key: <call_id> (notification_worker.rs). If the first POST succeeds but the response is lost/times out, a retry will create duplicate popups for the same call, which is exactly the failure mode idempotency keys are meant to prevent.
Useful? React with 👍 / 👎.
No description provided.