NHibernate Async Query API and ADO.NET Command Execution: Session State After CancellationToken Cancellation

NHibernate's async query API in the 5.x line accepts a CancellationToken, but the ORM delegates actual cancellation to the underlying ADO.NET provider's DbCommand.Cancel. This integration boundary means graceful cancellation depends on provider support rather than an ORM-level guarantee. When IQuery.SetTimeout is also configured, both the token and the timeout influence the same DbCommand, yet the provider may observe the token only between network reads rather than mid-query.

The unresolved decision concerns ISession state after a cancelled query. NHibernate does not define whether the session remains usable, must be disposed, or can safely retry, leaving cleanup to caller conventions. Because first-class async cancellation arrived with the NHibernate 5.x line, earlier versions lack CancellationToken overloads entirely and rely on synchronous CommandTimeout.

Is there a documented contract for ISession usability after a token-triggered cancellation? How should callers handle the case where CommandTimeout fires before the token, producing a provider-specific exception wrapped in a generic ADOException? What verification confirms whether a target ADO.NET provider observes cancellation between network reads or only at command boundaries?