You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs(event_handler): finish API Gateway WebSocket resolver docs
Adds the overview and workflow mermaid diagrams, accessing the event
and Lambda context, and the sending-messages recipe: a connection
store capturing connection_id and callback_url at $connect, an
in-resolver broadcast, and a separate function pushing a result to
the requesting client later — with GoneException handling,
ManageConnections IAM, and a custom domain caveat.
* Route WebSocket events by route key with dedicated `$connect`, `$disconnect`, and `$default` decorators
@@ -185,6 +211,109 @@ Register handlers for specific exception types with `@app.exception_handler`; it
185
211
???+ note "Unhandled exceptions never reach the client"
186
212
An exception with no registered handler is logged and becomes a bare `{"statusCode": 500}`. If it propagated to the Lambda runtime instead, the runtime's error response — exception type, message, and stack trace — would be delivered to the connected client.
187
213
214
+
### Accessing the event and Lambda context
215
+
216
+
Inside handlers and middlewares, `app.current_event` is the current `APIGatewayWebSocketEvent` ([Event Source Data Classes](../../utilities/data_classes.md){target="_blank"} utility) and `app.lambda_context` is the Lambda context.
217
+
218
+
Use `app.append_context` / `app.context` to share data between middlewares and handlers within a single invocation — the context is cleared after each `resolve`.
1. Route, connection, and identity details live in `request_context`.
227
+
2. `json_body` parses the message body; `body` and `decoded_body` are also available.
228
+
3. The standard Lambda context object.
229
+
230
+
### Sending messages to connected clients
231
+
232
+
Returned bodies only reply to the **calling** client, on routes with a route response. To push a message to a client at any time — including after the invocation that received the request has long finished — call the API Gateway Management API's `PostToConnection` with the connection ID, against the endpoint the `callback_url` property gives you.
233
+
234
+
Capture `connection_id` and `callback_url` together at `$connect` and persist them: that record is everything **any** process needs to push to that client later.
235
+
236
+
The example shows both sending situations. Inside the resolver, `broadcast` pushes to every stored connection from the same invocation, building the client from the current event.
237
+
238
+
Outside it, `submitReport` acknowledges a long-running request immediately, and a **separate Lambda function** — for example the final state of a Step Functions workflow — pushes the finished result to the one client that asked, using the stored `callback_url`. Progress updates are that same call made mid-work.
239
+
240
+
A stale connection ID raises `GoneException` — the client is no longer connected, so treat it as a signal to remove that connection from your store. The posting function also needs the `execute-api:ManageConnections` IAM permission on `arn:aws:execute-api:{region}:{account}:{api-id}/{stage}/POST/@connections/*`.
1. The only thing the WebSocket resolver and the pushing function share.
249
+
2. Captured at `$connect`: the only moment you get for free, and all anyone needs to post to this client later.
250
+
3. Acknowledge immediately; the result is pushed by another function when it is ready. For the ack to reach the client, configure a route response on `submitReport`.
251
+
4. Sending from inside the resolver: the current event provides the endpoint directly.
`callback_url` is built from the event's domain name. When clients connect through a custom domain whose API mapping path differs from the stage name, construct the endpoint yourself instead: `https://{api_id}.execute-api.{region}.amazonaws.com/{stage}`.
0 commit comments