Validate Telegram webhook and command config by rissrice2105-agent · Pull Request #613 · profullstack/sh1pt

rissrice2105-agent · 2026-06-05T18:27:52Z

Fixes #612.

Changes:

validate webhookUrl as an HTTPS URL before build or ship
validate Telegram command names and non-empty descriptions before dry-run or real shipping
reuse normalized command payloads for API calls
add regression tests for invalid webhook URLs, commands, and remote API errors

Validation:

vitest run packages/targets/chat-telegram/src/index.test.ts
tsc -p packages/targets/chat-telegram/tsconfig.json --noEmit

greptile-apps · 2026-06-05T18:31:23Z

Greptile Summary

This PR adds early-exit validation for the Telegram adapter: webhookUrl is now checked to be a valid HTTPS URL before the build or ship step proceeds, and command names/descriptions are validated and normalized (slash-stripped, lowercased) before any dry-run or live API call is made.

requireWebhookUrl is called in both build and ship; normalizeCommand (including the new format checks) is called in ship only, so invalid command configs are not caught at build time.
Four new tests cover the invalid-URL, invalid-command-name, blank-description, and remote-API-error paths; the existing API-error test is updated to supply a valid HTTPS URL so the new validation does not short-circuit it.

Confidence Score: 4/5

Safe to merge; the new validation paths are straightforward and well-tested, with no changes to the Telegram API call flow itself.

The two observations are both non-blocking: commands going unvalidated during build defers errors to ship rather than preventing them, and the trailing-slash normalization only affects bare-domain webhook URLs which are uncommon in practice. Core ship logic, token handling, and command normalization are all correct.

packages/targets/chat-telegram/src/index.ts — specifically the requireWebhookUrl return value and the absence of command validation in build.

Important Files Changed

Filename	Overview
packages/targets/chat-telegram/src/index.ts	Adds HTTPS URL validation and command name/description normalization. Logic is correct; two minor gaps: commands are not validated during the build step, and url.toString() can add a trailing slash for bare-domain webhook URLs.
packages/targets/chat-telegram/src/index.test.ts	Adds three new regression tests covering invalid HTTP webhook URL, invalid command name, and blank description; also updates the API-error test to use a valid HTTPS URL. All assertions are substring matches that align with the implementation error strings.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A([User calls build / ship]) --> B{build or ship?}
    B -->|build| C[normalizeUsername]
    C --> D[requireWebhookUrl validate HTTPS]
    D -->|invalid| E1[throw: webhookUrl must be HTTPS]
    D -->|valid| F[return artifact path]
    B -->|ship| G[normalizeUsername]
    G --> H[requireWebhookUrl validate + normalize]
    H -->|invalid| E2[throw: webhookUrl must be HTTPS]
    H -->|valid| I[commands.map normalizeCommand]
    I -->|invalid command| E3[throw: command format error]
    I -->|valid| J{dryRun?}
    J -->|yes| K[return dry-run id]
    J -->|no| L[lookup bot token from vault]
    L -->|missing| E4[throw: token not in vault]
    L -->|found| M[callTelegram setWebhook]
    M --> N{commands?}
    N -->|yes| O[callTelegram setMyCommands]
    N -->|no| P[optional description calls]
    O --> P
    P --> T[return id + url]

_{Reviews (1): Last reviewed commit: "Validate Telegram webhook and command co..." | Re-trigger Greptile}

greptile-apps · 2026-06-05T18:31:28Z

  async build(ctx, config) {
    const username = normalizeUsername(config.botUsername);
+    requireWebhookUrl(config.webhookUrl);
    ctx.log(`telegram prepare bot manifest for @${username}`);
    return { artifact: join(ctx.outDir, `telegram-${safeFilename(username)}.json`) };
  },


Command validation skipped in build

requireWebhookUrl is called in build but config.commands is never validated here. A config with a valid webhookUrl but malformed commands (e.g. a space in the command name or a blank description) will pass build successfully and only fail when ship is called — even in dry-run mode. The failure surfaces later than users would expect, after the manifest artifact path has already been returned.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

greptile-apps · 2026-06-05T18:31:29Z

+function requireWebhookUrl(value: string): string {
+  let url: URL;
+  try {
+    url = new URL(value);
+  } catch {
+    throw new Error('chat-telegram webhookUrl must be a valid HTTPS URL');
+  }
+  if (url.protocol !== 'https:' || !url.hostname) {
+    throw new Error('chat-telegram webhookUrl must be a valid HTTPS URL');
+  }
+  return url.toString();
+}


url.toString() may silently add a trailing slash

new URL('https://example.com').toString() returns 'https://example.com/' — the WHATWG parser adds a trailing / to the path for bare-domain URLs. The normalized string is then sent verbatim to Telegram's setWebhook. If the webhook server or a monitoring tool compares the registered URL to the configured one, the silently added slash can cause mismatches. URLs with an explicit path (e.g. https://example.com/telegram) are unaffected, but it is worth preserving the original value (after HTTPS-protocol validation) rather than returning the serialized URL object.

github-actions · 2026-06-06T07:13:37Z