telega_wisp - v3.0.0

telega_wisp

Values

default_health_path

</> 
pub const default_health_path: String

The path handle_health answers on by default.

handle_bot

</> 
pub fn handle_bot(
  telega telega: telega.Telega(session, error, dependencies),
  req req: request.Request(wisp.Connection),
  next handler: fn() -> response.Response(wisp.Body),
) -> response.Response(wisp.Body)

A middleware function to handle incoming requests from the Telegram API. Handles a request to the bot webhook endpoint, decodes the incoming message, validates the secret token, and passes the message to the bot for processing.

import wisp.{type Request, type Response}
import telega.{type Bot}
import telega_wisp

fn handle_request(bot: Bot, req: Request) -> Response {
  use <- telega_wisp.handle_bot(req, bot)
  // ...
}

handle_bot_with_reply

</> 
pub fn handle_bot_with_reply(
  telega telega: telega.Telega(session, error, dependencies),
  req req: request.Request(wisp.Connection),
  timeout timeout: Int,
  next handler: fn() -> response.Response(wisp.Body),
) -> response.Response(wisp.Body)

Like handle_bot, but lets the handler answer the update directly in the webhook HTTP response body (webhook reply), saving one HTTP round-trip for the first eligible API call.

Unlike handle_bot, the request process waits up to timeout ms for the handler to either claim a reply or finish; after the timeout it answers an empty 200 OK and the handler keeps running in the background. Pick a timeout safely below Telegram’s webhook timeout — e.g. 5000 ms.

⚠️ A claimed call resolves to a synthetic stub inside the handler (True for boolean methods, a fake Message for sendMessage). Full guide in telega’s telega/webhook_reply module docs.

handle_health

</> 
pub fn handle_health(
  telega telega: telega.Telega(session, error, dependencies),
  req req: request.Request(wisp.Connection),
  path path: String,
  next handler: fn() -> response.Response(wisp.Body),
) -> response.Response(wisp.Body)

Answer a health probe on path (no leading slash), and let every other request through to next.

GET /healthz answers 200 with {"status":"healthy","in_flight":3,"chat_instances":41} while the bot actor is alive, accepting updates, and below the cap set by telega.with_max_in_flight; 503 with the same shape (draining, overloaded, unavailable) otherwise. That is what a load balancer, a Kubernetes readiness probe or a fly.io health check wants: a deploy drains out of rotation instead of black-holing updates.

fn handle_request(bot: Telega(s, e, d), req: Request) -> Response {
  use <- telega_wisp.handle_health(telega: bot, req:, path: telega_wisp.default_health_path)
  use <- telega_wisp.handle_bot(telega: bot, req:)
  // ... your own routes
}
✨ Search Document