"Request timeout exceeded" from Apollo Server timeout plugin: do resolvers keep running after abort?

I am designing timeout and cancellation handling for a GraphQL HTTP API and need to pin down one behavior before committing to an architecture. When a timeout middleware such as Apollo Server's timeout plugin fires, the client receives a generic Internal Server Error with a message like Request timeout exceeded, but it is unclear what happens to resolver execution that is already in flight.

Some servers expose the underlying request's abort signal (for example via context.signal in GraphQL Yoga), while others require manual extraction, and implementations differ on whether they interrupt resolvers or let them run to completion after the response is abandoned. The GraphQL specification also does not define transactional semantics, so any side effects a resolver performed before the timeout are not automatically rolled back.

Assume a current Apollo Server or Yoga version with a resolver that performs a slow database write followed by a slow read.

Does the timeout plugin actually signal resolvers to stop, or does it only abandon the HTTP response while execution continues? If a client aborts via AbortController before the server timeout, is that propagated to resolvers through the same mechanism? And is there a documented pattern for compensating partial side effects when cancellation lands mid-operation?