Skip to content

feat: add BotHostWithHTTPClient and TelegramRedirectTransport - #56

Merged
trakhimenok merged 1 commit into
mainfrom
feat/telegram-redirect-transport
Jul 25, 2026
Merged

feat: add BotHostWithHTTPClient and TelegramRedirectTransport#56
trakhimenok merged 1 commit into
mainfrom
feat/telegram-redirect-transport

Conversation

@trakhimenok

Copy link
Copy Markdown
Contributor

Summary

  • BotHost() hardcodes http.DefaultClient for GetHTTPClient, so nothing running this host can redirect its outbound Bot API calls anywhere else. The only implementation that redirects Telegram traffic lived test-only, inside a Sneat consumer repo (sneat-go/pkg/bots/botinit/listus_branching_host_test.go), driven only through go test, never as reusable/production code.
  • Adds BotHostWithHTTPClient(client *http.Client) botHostInterface — additive, alongside BotHost(). BotHost() is unchanged and still always returns http.DefaultClient; existing callers see no behaviour change.
  • Adds TelegramRedirectTransport, an exported http.RoundTripper (via NewTelegramRedirectTransport(baseURL, base)) that rewrites requests bound for api.telegram.org to a caller-supplied base URL and rejects every other destination — a closed network boundary, not a general HTTP proxy. Modeled directly on the proven test-only listusBranchingTelegramTransport in sneat-go.

Why

Sneat's Listus bot needs to be reachable by a Chatwright Telegram Platform Emulator for AI-goal exploration. bots-api-telegram's tgbotapi.APIEndpoint is a hardcoded const (no override), and changing it would touch a framework every production Sneat bot depends on — out of scope. The only viable seam is botsfw.BotHost.GetHTTPClient, and this repo's production BotHost() had no way to control it. This closes that gap in the shared, owned dependency instead of building a local workaround downstream (sneat-go gets only wiring — see its own PR).

Test plan

  • gofmt -l . clean
  • GOWORK=off go vet ./...
  • GOWORK=off go test -race ./... — all pass, including new tests for BotHostWithHTTPClient and TelegramRedirectTransport (nil-baseURL rejection, incomplete-baseURL rejection, non-Telegram-host rejection, correct rewrite/forward, BotHost() unaffected)
  • golangci-lint run ./... clean

Versioning

Not tagged yet — see the companion sneat-go PR / session report for what tag this needs before sneat-go can consume it as a real (non-replace) dependency.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SkkrXdtf8mU2GRo2hHsHT1

Production BotHost() hardcodes http.DefaultClient, so nothing can redirect
a bot's outbound Bot API calls. The only redirect implementation lived
test-only in a Sneat consumer repo. Promote that pattern to exported,
reusable code here: BotHostWithHTTPClient(client) is an additive
constructor alongside BotHost() (which keeps returning http.DefaultClient
exactly as before), and TelegramRedirectTransport is an http.RoundTripper
that rewrites api.telegram.org requests to a caller-supplied base URL and
rejects every other destination, closing the network boundary rather than
opening a general-purpose proxy.

This lets a caller (e.g. a dev/test host wired to a Chatwright Telegram
Platform Emulator) redirect outbound Telegram traffic without touching
bots-api-telegram's hardcoded APIEndpoint constant, which all production
Sneat bots depend on.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SkkrXdtf8mU2GRo2hHsHT1
Signed-off-by: Alexander Trakhimenok <alex@trakhimenok.com>
@trakhimenok
trakhimenok merged commit 1cc08c7 into main Jul 25, 2026
3 checks passed
@trakhimenok
trakhimenok deleted the feat/telegram-redirect-transport branch August 19, 2026 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant