polygram 0.6.5 → 0.6.6

package/lib/db.js

@@ -337,10 +337,23 @@ function wrap(db) {
     // Dedupe check: did we already send an outbound reply to this inbound?
     // Prevents double-processing if a redelivered/replayed message has
     // already been answered.
+    //
+    // We also count rows in the special 'failed crashed-mid-send' state
+    // as "probably sent" for dedupe. Those rows were created when polygram
+    // crashed AFTER inserting the pending row but before marking it sent
+    // — the API call may or may not have actually reached Telegram. The
+    // boot-time markStalePending sweep flips them to 'failed' with the
+    // 'crashed-mid-send' sentinel error. Treating them as un-replied
+    // (status='sent' only) caused boot replay to re-dispatch and Telegram
+    // delivered the SAME answer twice. Treating them as replied risks the
+    // opposite (the user never got a reply because the API truly failed
+    // before reaching Telegram), but a missed reply is recoverable —
+    // the user resends — while a duplicate reply is not.
     hasOutboundReplyTo({ chat_id, msg_id }) {
       const row = db.prepare(`
         SELECT 1 FROM messages
-         WHERE chat_id = ? AND direction = 'out' AND reply_to_id = ? AND status = 'sent'
+         WHERE chat_id = ? AND direction = 'out' AND reply_to_id = ?
+           AND (status = 'sent' OR (status = 'failed' AND error = 'crashed-mid-send'))
          LIMIT 1
       `).get(chat_id, msg_id);
       return !!row;

package/lib/prompt.js

@@ -32,17 +32,6 @@ function truncateReplyText(s, max = REPLY_TO_MAX_CHARS) {
   return `${s.slice(0, head)}…${s.slice(-tail)}`;
 }
 
-/**
- * Attachment summary for reply-to (never embed full content).
- */
-function summarizeReplyAttachments(attachmentsJson) {
-  if (!attachmentsJson) return '';
-  let items;
-  try { items = JSON.parse(attachmentsJson); } catch { return ''; }
-  if (!Array.isArray(items) || !items.length) return '';
-  return items.map((a) => `[${a.kind}: ${a.name}]`).join(' ');
-}
-
 /**
  * Build a reply-to block. Callers pass either:
  *   - { telegram: msg.reply_to_message } (canonical Telegram payload), or
@@ -71,15 +60,22 @@ ${xmlEscape(body)}
   }
 
   if (dbRow) {
+    // Attachment summary for the reply-to block used to read
+    // dbRow.attachments_json, but that column was dropped in migration
+    // 008. Per-attachment rows live in the `attachments` table now;
+    // building a summary here would need a separate join. For reply-to
+    // context Claude already sees the canonical Telegram payload via
+    // the `telegram` branch above (the DB-row path is only the fallback
+    // for resurrected/replayed messages where the live payload is
+    // unavailable). Skipping the summary here is acceptable — text
+    // alone is enough context for "this is what they replied to".
     const ts = dbRow.ts ? new Date(dbRow.ts).toISOString() : '';
     const text = truncateReplyText(dbRow.text || '');
-    const attachSummary = summarizeReplyAttachments(dbRow.attachments_json);
-    const body = [text, attachSummary].filter(Boolean).join('\n');
     const editedAttr = dbRow.edited_ts
       ? ` edited_ts="${new Date(dbRow.edited_ts).toISOString()}"`
       : '';
     return `<reply_to msg_id="${dbRow.msg_id}" user="${xmlEscape(dbRow.user || 'Unknown')}" ts="${ts}"${editedAttr} source="bridge-db">
-${xmlEscape(body)}
+${xmlEscape(text)}
 </reply_to>`;
   }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "polygram",
-  "version": "0.6.5",
+  "version": "0.6.6",
   "description": "Telegram daemon for Claude Code that preserves the OpenClaw per-chat session model. Migration path for OpenClaw users moving to Claude Code.",
   "main": "lib/ipc-client.js",
   "bin": {

package/polygram.js

@@ -487,7 +487,15 @@ async function downloadAttachments(bot, token, chatId, msg, rows) {
       // <attachment-failed reason="..." /> so claude tells the user
       // "I couldn't see your <kind>" instead of pretending it received
       // text only.
-      const reason = (err.message || 'unknown').slice(0, 200);
+      //
+      // Token redaction: the fetch URL embeds bot${TOKEN} (Telegram CDN
+      // requirement) and some undici/network error variants stringify
+      // the request including the URL into err.message. Persisting that
+      // raw to attachments.download_error or stderr would leak the bot
+      // token to anyone with DB or log access. Strip any `bot<token>`
+      // pattern from the reason before storing/logging.
+      const raw = (err.message || 'unknown').slice(0, 200);
+      const reason = raw.replace(/bot\d+:[A-Za-z0-9_-]+/g, 'bot<redacted>');
       console.error(`[attach] download failed for ${att.name}: ${reason}`);
       results.push({ ...att, path: null, error: reason });
       dbWrite(() => db.markAttachmentFailed(att.id, reason),
@@ -1495,7 +1503,19 @@ async function handleMessage(sessionKey, chatId, msg, bot) {
         chat_id: chatId, text: `Attachment(s) skipped: ${summary.slice(0, 300)}`,
         ...replyOpts(threadId),
       }, { source: 'attachment-skipped', botName: BOT_NAME });
-    } catch {}
+    } catch (err) {
+      // Surface the failure: claude is about to reply as if the photo
+      // was processed (because filterAttachments dropped it before
+      // download), and the user would otherwise have no signal that
+      // their attachment was rejected. They'd assume claude saw it
+      // and is just answering oddly.
+      console.error(`[${label}] failed to notify user of skipped attachments: ${err.message}`);
+      dbWrite(() => db.logEvent('attachment-skip-notice-failed', {
+        chat_id: chatId, msg_id: msg.message_id,
+        error: err.message?.slice(0, 200),
+        rejected_count: rejected.length,
+      }), 'log attachment-skip-notice-failed');
+    }
   }
 
   await transcribeVoiceAttachments(downloaded, {