feat(telegram): support sendMessageDraft streaming in DMs#159
feat(telegram): support sendMessageDraft streaming in DMs#159
Conversation
…ring `"undefined"` (truthy) instead of removing it, leaking a truthy VERCEL env var into subsequent tests.
This commit fixes the issue reported at packages/adapter-telegram/src/index.test.ts:661
**Bug explanation:**
In the test "auto mode stays in webhook mode on serverless runtime" (line 622), the cleanup code in the `finally` block at line 662 uses `process.env.VERCEL = undefined` when the env var wasn't previously set. In Node.js, `process.env` coerces all values to strings, so `process.env.VERCEL = undefined` actually sets `process.env.VERCEL` to the string `"undefined"`. This is truthy (`Boolean("undefined")` === `true`).
This was verified empirically:
```
process.env.TEST_VAR = undefined;
typeof process.env.TEST_VAR // "string"
process.env.TEST_VAR // "undefined"
Boolean(process.env.TEST_VAR) // true
```
The consequence is that after this test runs, `process.env.VERCEL` remains set to the truthy string `"undefined"`, causing `isLikelyServerlessRuntime()` to return `true` for all subsequent tests that run in the same process. This could cause any auto-mode tests that follow to incorrectly detect a serverless runtime and behave differently than expected.
**Fix explanation:**
Changed `process.env.VERCEL = undefined` to `delete process.env.VERCEL`, which properly removes the environment variable from `process.env`. After `delete`, `process.env.VERCEL` is `undefined` (the actual undefined value, not the string), and `Boolean(process.env.VERCEL)` correctly returns `false`. This matches the standard pattern for cleaning up environment variables in Node.js tests.
Co-authored-by: Vercel <vercel[bot]@users.noreply.github.com>
Co-authored-by: timolins <me@timo.sh>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…ssagedraft-streaming # Conflicts: # packages/adapter-telegram/src/index.ts
…ssagedraft-streaming
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
… convention Telegram always assigns negative IDs to groups/supergroups/channels and positive IDs to private chats, making this a reliable heuristic. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Previously, if sendMessageDraft failed after the first successful draft update, the adapter silently disabled draft streaming and the user saw no updates until the final message posted. Now any draft failure immediately falls back to post+edit streaming with the remaining chunks, ensuring a consistent streaming UX. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…elapses Only call renderStreamMarkdown when the throttle interval has passed, avoiding redundant parse+render cycles on every incoming chunk. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Apply the same time-check-first optimization to streamViaPostEdit: skip renderStreamMarkdown entirely when the throttle interval hasn't elapsed, avoiding redundant parse+render cycles on every chunk. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace verbose typeof guards with globalThis.crypto?.randomUUID?.() and nullish coalescing fallback. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Hey Timo! Great PR — the draft streaming approach is really clean. I pushed a few follow-up fixes after reviewing: What changed
All changes pass |
2 participants
Summary
stream()support in Telegram adapter usingsendMessageDraftfor private chatssendMessageDraftis unavailableDraft API (DMs) + Post+EditbehaviorVerification
pnpm --filter @chat-adapter/telegram typecheckpnpm --filter @chat-adapter/telegram testNotes
sendMessageDraftwas introduced in Bot API 9.5 and is currently DM-scoped in this adapter path.