Skip resume reprocess confirmation for contact selection#202
Conversation
|
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: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ 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 CRM resume-reprocess “multiple match → contact selection” flows to skip the extra confirmation step and start the resume reprocess runner immediately after a contact is selected.
Changes:
- Swapped contact-selection callbacks to call a new direct-start helper instead of prompting for reprocess confirmation.
- Added
_start_resume_reprocess_from_contactto resolve the latest resume attachment, fall back to the upload-resume handoff when missing, and invoke the existing extract/preview flow.
Comments suppressed due to low confidence (1)
apps/discord_bot/src/five08/discord_bot/cogs/crm.py:478
- This change replaces
_prompt_reprocess_resume_confirmationwith_start_resume_reprocess_from_contact, but existing unit tests still mock/assert on_prompt_reprocess_resume_confirmationfor the selection-button path (e.g.,tests/unit/test_crm.py::test_reprocess_resume_selection_button_without_resume_hands_off_to_upload). Update the tests to mock/assert the new helper and add a test that a “has resume” selection triggers_run_resume_extract_and_preview(or_start_resume_reprocess_from_contact) with the expected args so CI doesn’t break and the new behavior stays covered.
await interaction.response.defer(ephemeral=True)
if self.has_resume:
await self.view.crm_cog._start_resume_reprocess_from_contact(
interaction=interaction,
contact=self.contact,
search_term=self.view.search_term,
)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| async def _start_resume_reprocess_from_contact( | ||
| self, | ||
| interaction: discord.Interaction, | ||
| contact: dict[str, Any], | ||
| search_term: str, | ||
| ) -> None: | ||
| """Start resume reprocessing for a selected contact without extra confirmation.""" | ||
| raw_contact_id = contact.get("id") | ||
| contact_id = str(raw_contact_id).strip() if raw_contact_id is not None else "" | ||
| if not contact_id: | ||
| self._audit_command( | ||
| interaction=interaction, | ||
| action="crm.reprocess_resume", | ||
| result="error", | ||
| metadata={ | ||
| "search_term": search_term, | ||
| "reason": "contact_id_missing", | ||
| }, | ||
| ) | ||
| await interaction.followup.send("❌ Contact ID not found.") | ||
| return | ||
|
|
||
| contact_name = str(contact.get("name", "Unknown")) | ||
| ( | ||
| attachment_id, | ||
| filename, | ||
| ) = await self._get_latest_resume_attachment_for_contact(contact_id) | ||
| if not attachment_id: |
There was a problem hiding this comment.
_start_resume_reprocess_from_contact largely duplicates the contact-id + latest-resume resolution logic from _prompt_reprocess_resume_confirmation, but the two flows already diverge (e.g., missing-resume auditing/messaging). Consider extracting a shared internal resolver (e.g., “get contact_id/contact_name/latest attachment or upload-handoff”) and have both methods call it, to avoid future behavior drift and double-maintenance when the resolution rules change.
Description
This removes the extra confirmation prompt when selecting a contact from multiple-match reprocess flows.
Both interactive contact-selection paths now start resume reprocessing directly after selection, while reusing existing extraction and status logic.
A new helper resolves the latest resume, falls back to upload guidance when none exists, and kicks off the existing extraction flow.
Related Issue
How Has This Been Tested?
Not run in this environment yet; changes were reviewed via the focused diff and should be exercised in Discord for reprocess-relevant flows.