[codex] Close lost Discord gig posts#303
Conversation
|
Warning Review limit reached
Your plan currently allows 1 review/hour. Refill in 50 minutes and 55 seconds. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more review capacity refills, 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 trial, open-source, and free plans. In all cases, review capacity refills continuously over time. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThis PR extends Discord gig-thread status synchronization to explicitly handle the LOST state. The API route now detects when a thread should be closed (locked and archived) based on the normalized engagement status, the cog performs a sequence of idempotent Discord edits (unarchive if needed, rename, then lock/archive), and the user-facing confirmation message reflects both the rename and close actions for LOST transitions. ChangesThread LOST Status and Close Handling
Sequence DiagramsequenceDiagram
participant Client
participant InternalAPI as Internal API Route
participant Cog as Jobs Cog
participant Discord as Discord Thread
Client->>InternalAPI: POST gig thread status to LOST
InternalAPI->>InternalAPI: Compute should_close_thread=true for LOST
InternalAPI->>InternalAPI: Compute needs_close=true if not locked/archived
InternalAPI->>Cog: Pass should_close_thread, status, title
Cog->>Cog: Compute needs_rename, needs_close
Note over Cog: Edit sequence if needed:<br/>1. Unarchive if already archived<br/>2. Rename thread<br/>3. Lock + Archive
Cog->>Discord: thread.edit(name="[LOST] ...")
Discord->>Discord: Update thread name
Cog->>Discord: thread.edit(locked=true, archived=true)
Discord->>Discord: Lock and archive thread
Cog->>InternalAPI: Return closed=true, updated status
InternalAPI->>Client: 200 OK with closed=true
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
There was a problem hiding this comment.
Pull request overview
This PR updates the Discord bot’s gig-thread status syncing so that when a gig becomes LOST, the associated Discord forum thread is not only renamed with the [LOST] marker but also locked and archived. This applies both to the dashboard-driven internal API sync and the /update-gig-status lost slash-command path.
Changes:
- Lock + archive Discord gig threads when the engagement status becomes
lost(dashboard sync + slash command). - Extend internal API responses to include whether the thread was “closed”.
- Add unit tests covering the new lost-thread closing behavior.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
apps/discord_bot/src/five08/discord_bot/utils/internal_api.py |
Update dashboard status sync to lock/archive threads for LOST gigs and return closed state. |
apps/discord_bot/src/five08/discord_bot/cogs/jobs.py |
Update /update-gig-status rename helper to lock/archive for LOST gigs and tweak user confirmation messaging. |
tests/unit/test_internal_api.py |
Add test asserting LOST dashboard updates lock/archive the thread and report closed=True. |
tests/unit/test_jobs.py |
Add test asserting LOST slash-command path locks/archives the thread after renaming. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 009970f38d
ℹ️ 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".
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/discord_bot/src/five08/discord_bot/cogs/jobs.py (1)
2376-2397:⚠️ Potential issue | 🟠 Major | ⚡ Quick winNon-LOST status changes do not reopen previously closed threads.
Once a thread is closed for LOST, switching to another status does not clear
locked/archived, so the thread can remain closed unexpectedly.Suggested fix
should_close_thread = status is EngagementStatus.LOST + should_reopen_thread = not should_close_thread and ( + not not getattr(thread, "locked", False) + or not not getattr(thread, "archived", False) + ) needs_rename = thread.name != next_name needs_close = should_close_thread and ( not getattr(thread, "locked", False) or not getattr(thread, "archived", False) ) - if not needs_rename and not needs_close: + if not needs_rename and not needs_close and not should_reopen_thread: return next_name @@ - if getattr(thread, "archived", False) and (needs_rename or needs_close): + if getattr(thread, "archived", False) and ( + needs_rename or needs_close or should_reopen_thread + ): await thread.edit(archived=False, reason=reason) if needs_rename: await thread.edit(name=next_name, reason=reason) if should_close_thread: await thread.edit(locked=True, archived=True, reason=reason) + elif should_reopen_thread: + await thread.edit(locked=False, archived=False, reason=reason)🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@apps/discord_bot/src/five08/discord_bot/cogs/jobs.py` around lines 2376 - 2397, The code only reopens threads when should_close_thread is True, so switching from LOST to another status leaves threads archived/locked; update the logic in the block around should_close_thread / getattr(thread, "archived", False) so that when should_close_thread is False but the thread is currently archived or locked you call await thread.edit(archived=False, locked=False, reason=reason) before any rename; specifically adjust the flow where you compute needs_close and where you call thread.edit so that non-LOST transitions clear archived and locked on the thread (use EngagementStatus.LOST, thread, needs_rename, needs_close, and thread.edit) to ensure the thread is reopened prior to renaming or further edits.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@apps/discord_bot/src/five08/discord_bot/utils/internal_api.py`:
- Around line 376-377: Replace the narrow "thread_rename_forbidden" error key in
the except discord.Forbidden handler with a generic update-scoped forbidden key
(e.g. "thread_update_forbidden") to cover rename/unarchive/lock/archive
failures; update the except discord.Forbidden block in internal_api.py so it
returns {"error": "thread_update_forbidden"}, 403 (keeping the 403 status)
instead of the current "thread_rename_forbidden".
- Around line 345-387: The code never re-opens threads moved away from LOST:
compute a needs_open flag (e.g. needs_open = not should_close_thread and
(getattr(channel, "locked", False) or getattr(channel, "archived", False)))
alongside needs_rename/needs_close, and include it in the early-return check;
then in the update block, if needs_open await channel.edit(archived=False,
locked=False, reason="Dashboard gig status update") (before renaming) so threads
are unarchived/unlocked when status transitions off EngagementStatus.LOST; keep
existing exception handling and ordering (unarchive/unlock before rename, and
only lock+archive when should_close_thread).
---
Outside diff comments:
In `@apps/discord_bot/src/five08/discord_bot/cogs/jobs.py`:
- Around line 2376-2397: The code only reopens threads when should_close_thread
is True, so switching from LOST to another status leaves threads
archived/locked; update the logic in the block around should_close_thread /
getattr(thread, "archived", False) so that when should_close_thread is False but
the thread is currently archived or locked you call await
thread.edit(archived=False, locked=False, reason=reason) before any rename;
specifically adjust the flow where you compute needs_close and where you call
thread.edit so that non-LOST transitions clear archived and locked on the thread
(use EngagementStatus.LOST, thread, needs_rename, needs_close, and thread.edit)
to ensure the thread is reopened prior to renaming or further edits.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1af4f7c5-10e0-4c1b-8394-23df4443b2a4
📒 Files selected for processing (4)
apps/discord_bot/src/five08/discord_bot/cogs/jobs.pyapps/discord_bot/src/five08/discord_bot/utils/internal_api.pytests/unit/test_internal_api.pytests/unit/test_jobs.py
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 01276af05d
ℹ️ 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".
| is_locked = bool(getattr(thread, "locked", False)) | ||
| is_archived = bool(getattr(thread, "archived", False)) | ||
| needs_rename = thread.name != next_name | ||
| needs_reopen = not should_close_thread and (is_locked or is_archived) |
There was a problem hiding this comment.
Avoid unlocking non-LOST threads unconditionally
This condition reopens any non-LOST thread whenever it is locked or archived, even if it was manually moderated rather than closed by the lost-status flow. In Discord, threads can be locked without being lost/closed, so a normal status sync (e.g., recruiting→filled, or even reapplying the same status) will silently clear moderator locks and unarchive the post. That is a behavioral regression introduced here and can override intentional moderation state; the reopen logic should be limited to threads that were previously closed due to LOST status.
Useful? React with 👍 / 👎.
Summary
lost./update-gig-status lostcommand path.Why
A gig marked as lost should no longer remain open for replies or look active in Discord. Previously, status updates only renamed the thread marker, leaving lost gig posts open.
Validation
uv run pytest tests/unit/test_internal_api.py tests/unit/test_jobs.pyuv run ruff check apps/discord_bot/src/five08/discord_bot/utils/internal_api.py apps/discord_bot/src/five08/discord_bot/cogs/jobs.py tests/unit/test_internal_api.py tests/unit/test_jobs.pyuv run ruff format --check apps/discord_bot/src/five08/discord_bot/utils/internal_api.py apps/discord_bot/src/five08/discord_bot/cogs/jobs.py tests/unit/test_internal_api.py tests/unit/test_jobs.pySummary by CodeRabbit
New Features
Bug Fixes