Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 17 minutes and 8 seconds. ⌛ 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)
WalkthroughUpdated a backend dependency and enhanced the ban-all moderation flow by recording an audit-log entry at initiation, running message deletion concurrently with the ban operation in the executor, and exposing a message-deletion helper as public. Changes
Sequence Diagram(s)mermaid Possibly related PRs
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
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 `@src/modules/moderation/ban-all.ts`:
- Around line 174-182: The audit log call using api.tg.auditLog.create.mutate
with the banAll payload should be best-effort: wrap that call in a try/catch so
any thrown error is caught, log the error (using the module logger or console)
with context (e.g., adminId/targetId/type) and continue execution so the
subsequent queue/job creation that uses banAll still runs even if audit logging
fails; do not change the success path or rethrow the error.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e64652dc-17dc-4f68-8d7f-1d69ec8af715
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (2)
package.jsonsrc/modules/moderation/ban-all.ts
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/modules/moderation/index.ts (1)
36-47:⚠️ Potential issue | 🔴 CriticalChange MUTE_ALL to UNBAN_ALL to align with ban-all feature and fix audit-log type mismatch.
The
MUTE_ALLentry at line 46 maps to"mute_all", but the audit-log type union expects"unban_all"instead. The ban-all feature in the codebase definesBanAllCommand = "ban_all" | "unban_all", confirming thatMUTE_ALLis incorrect and should beUNBAN_ALL. Update line 37's type annotation accordingly.Proposed fix
const MAP_ACTIONS: Record< - Exclude<ModerationAction["action"], "SILENT" | "MULTI_CHAT_SPAM"> | "BAN_ALL" | "MUTE_ALL", + Exclude<ModerationAction["action"], "SILENT" | "MULTI_CHAT_SPAM"> | "BAN_ALL" | "UNBAN_ALL", ApiInput["tg"]["auditLog"]["create"]["type"] > = { MUTE: "mute", BAN: "ban", KICK: "kick", UNBAN: "unban", UNMUTE: "unmute", BAN_ALL: "ban_all", - MUTE_ALL: "mute_all", + UNBAN_ALL: "unban_all", }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/modules/moderation/index.ts` around lines 36 - 47, The MAP_ACTIONS mapping uses the wrong key/value for the "unban all" case: replace the MUTE_ALL union member with UNBAN_ALL in the Record key type (the Exclude<ModerationAction["action"], ...> union) and update the object entry key from MUTE_ALL to UNBAN_ALL with the corresponding audit-log type value "unban_all" so MAP_ACTIONS (and its relation to ApiInput["tg"]["auditLog"]["create"]["type"]) matches the BanAllCommand ("ban_all" | "unban_all") and ModerationAction["action"] values.
♻️ Duplicate comments (1)
src/modules/moderation/ban-all.ts (1)
178-185:⚠️ Potential issue | 🟠 MajorAudit write is still a hard blocker before queue creation.
This is the same unresolved concern already raised in earlier review comments: failure here can prevent job creation at Line 187.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/modules/moderation/ban-all.ts` around lines 178 - 185, The audit write using api.tg.auditLog.create.mutate for the banAll record can throw and currently blocks subsequent queue/job creation; wrap the audit call (api.tg.auditLog.create.mutate) in a try/catch and ensure job/queue creation proceeds on failure (either log the error with context—include banAll.reporter.id and banAll.target.id—and continue, or move the audit write to after the queue creation and make it non-blocking), so that failures to persist the audit do not prevent the job from being enqueued/created.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/modules/moderation/ban-all.ts`:
- Around line 100-105: The code currently awaits this.shared.api.banChatMember
inside Promise.all which serializes the operations; remove the inner await so
both promises run in parallel by passing the banChatMember promise directly into
Promise.all alongside Moderation.deleteAllLastMessages(job.data.targetId,
job.data.chatId), preserving the .catch(() => false) on the ban promise to
handle errors; adjust the destructuring of the result (const [success]) to keep
behavior unchanged.
---
Outside diff comments:
In `@src/modules/moderation/index.ts`:
- Around line 36-47: The MAP_ACTIONS mapping uses the wrong key/value for the
"unban all" case: replace the MUTE_ALL union member with UNBAN_ALL in the Record
key type (the Exclude<ModerationAction["action"], ...> union) and update the
object entry key from MUTE_ALL to UNBAN_ALL with the corresponding audit-log
type value "unban_all" so MAP_ACTIONS (and its relation to
ApiInput["tg"]["auditLog"]["create"]["type"]) matches the BanAllCommand
("ban_all" | "unban_all") and ModerationAction["action"] values.
---
Duplicate comments:
In `@src/modules/moderation/ban-all.ts`:
- Around line 178-185: The audit write using api.tg.auditLog.create.mutate for
the banAll record can throw and currently blocks subsequent queue/job creation;
wrap the audit call (api.tg.auditLog.create.mutate) in a try/catch and ensure
job/queue creation proceeds on failure (either log the error with
context—include banAll.reporter.id and banAll.target.id—and continue, or move
the audit write to after the queue creation and make it non-blocking), so that
failures to persist the audit do not prevent the job from being
enqueued/created.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e5114e02-d1a9-455c-b294-1decdba75f85
📒 Files selected for processing (2)
src/modules/moderation/ban-all.tssrc/modules/moderation/index.ts
2 participants
No description provided.