Mastra’s September 16 Snowflake integration adds tools for submitting statements, checking them, fetching results and cancelling work. The useful discovery underneath is Snowflake’s existing HTTP lifecycle: a query can outlast the request that submitted it.
The provider’s submission guide accepts SQL at POST /api/v2/statements, with async=true available as a query parameter. Even without that option, clients must handle asynchronous responses. A 202 response supplies a statement handle; later requests can check that same statement.
A practical example: a report that survives a pause
Build a small data-quality assistant for a disposable warehouse. It submits a bounded, read-only count of missing values in a fixture table, stores the returned handle with its job record, and can check the result after its own process restarts. The application must save that record; the API does not persist the agent’s memory for it.
A status request uses GET /api/v2/statements/{statementHandle}. Pending responses need another check; successful execution returns results. Larger results can span partitions described by resultSetMetaData.partitionInfo. A successful first response should not be mistaken for the complete dataset.
Copyable agent instruction
Build a Snowflake SQL API demo against a disposable account fixture.
Use credentials supplied through the environment, never printed.
Use a role granted only the fixture reads and warehouse access it needs.
Start with SELECT 1 and then a bounded aggregate on an approved fixture.
Submit once with async=true. Persist statementHandle in a local job record.
On restart, resume GET status checks for that handle; do not resubmit it.
Distinguish pending, failed and completed states. Back off while pending
or throttled, and stop polling at a bounded deadline without claiming
that stopping the client cancelled the server query.
On success, inspect partitionInfo and fetch every required partition.
Demonstrate restart recovery with a saved pending job and mocked responses
before trying the authenticated service. Report which parts ran live.Access and test caveat
This is a documented design example, not a live Snowflake test. It needs an account, authentication, appropriate role grants and warehouse access; executing queries can consume warehouse resources. The API reference is the contract for request fields and responses. A read-only prompt is not a database permission boundary.
Mastra’s inspected execution tool accepts arbitrary SQL and optional role and bindings, but does not expose the API’s async query option. Its status and result tools are separate calls; the source does not make the whole recovery loop automatic. Our example therefore targets the provider API directly. Before relying on a wrapper, verify its installed version and exercise a pending query. The receipt is useful only if the application knows what to do when the answer has not arrived.