Skip to content

fix: prevent duplicate operator approval requests in Telegram bot #4420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
JHON12091986 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

fix: prevent duplicate operator approval requests in Telegram bot #4420

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions src/openhuman/telegram/bot.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
fn handle_operator_approval(message: &TelegramMessage) -> Result<()> {

@chatgpt-codex-connector chatgpt-codex-connector Bot Jul 2, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Wire the approval handler into the Telegram channel

This new handler is never compiled or called: src/openhuman/mod.rs does not declare a telegram module, and a repo-wide search only finds get_pending_approval, TelegramMessage, and handle_operator_approval inside this new file. The live Telegram approval path remains under src/openhuman/channels/providers/telegram/, so duplicate operator prompts for real Telegram messages will continue to use the old flow and this fix has no effect.

Useful? React with 👍 / 👎.

// Verificar si ya hay una solicitud pendiente para este usuario
if let Some(pending) = get_pending_approval(message.from.id) {
// Si ya hay una solicitud pendiente, no crear una nueva
return Ok(());
}

// Crear una nueva solicitud de aprobación
create_approval_request(message.from.id, message.text)?;
Comment on lines +3 to +9

@coderabbitai coderabbitai Bot Jul 2, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | 🏗️ Heavy lift

Check-then-create is not atomic — race condition can still send duplicate approval requests.

The exact bug this PR intends to fix (duplicate approval requests) can still occur if two messages from the same sender arrive concurrently: both can pass the get_pending_approval check as None before either calls create_approval_request. Given the approval store snippets show pending_approvals.request_id as the PRIMARY KEY CREATE TABLE IF NOT EXISTS pending_approvals ( request_id TEXT PRIMARY KEY, but no unique constraint on sender, nothing at the persistence layer prevents duplicate rows for the same user either.

Consider making the check-and-insert atomic (e.g., a single transaction, a DB-level uniqueness constraint on the sender/session key, or a mutex keyed by sender id) rather than two separate calls.

🤖 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 `@src/openhuman/telegram/bot.rs` around lines 3 - 9, The approval-request flow
is still vulnerable to duplicate sends because
`get_pending_approval(message.from.id)` and
`create_approval_request(message.from.id, message.text)` are separate non-atomic
steps. Update the logic around this bot handler so the pending-check and insert
happen atomically, using either a transaction, a sender-keyed mutex, or a
database-level uniqueness constraint on the sender/session key. Also review the
persistence layer for `pending_approvals` so the schema prevents duplicate rows
for the same user, not just duplicate `request_id` values.


Ok(())
}
Loading