Expand description
Execution contexts for queries and mutations.
Every function receives a context providing access to:
- Database connection (pool or transaction)
- Authentication state (user ID, roles, claims)
- Request metadata (request ID, trace ID, client IP)
- Environment variables
- Job/workflow dispatch (mutations only)
§QueryContext vs MutationContext
| Feature | QueryContext | MutationContext |
|---|---|---|
| Database | Pool (read-only) | Transaction or pool |
| Dispatch jobs | No | Yes |
| Start workflows | No | Yes |
| HTTP client | No | Yes (circuit breaker) |
§Transactional Mutations
When transactional = true (default), mutations run in a transaction.
Jobs and workflows dispatched during the mutation insert their rows on
the same transaction, so they only become visible to workers once the
mutation commits and are rolled back if it fails.
BEGIN
├── ctx.tx().execute(...)
├── ctx.dispatch_job("send_email", ...) // INSERT into forge_jobs on this tx
└── return Ok(result)
COMMITStructs§
- Auth
Context - Authentication context available to all functions.
- Auth
Token Ttl - Token TTL configuration resolved from
[auth]in forge.toml. - ForgeDb
- Pool wrapper that adds
db.querytracing spans to every database operation. - Mutation
Context - Context for mutation functions (transactional database access).
- Query
Context - Context for query functions (read-only database access).
- Request
Metadata - Request metadata available to all functions.
Enums§
- DbConn
- Abstraction over pool and transaction connections.
- Forge
Conn - Connection wrapper that implements sqlx’s
Executortrait with automaticdb.querytracing spans.
Traits§
- Token
Issuer - Token issuer for signing JWTs.