graphql-go fixes subscription timeout sends after cancellation

graphql-go is a Go GraphQL implementation, and its recent activity addresses subscription cleanup when timeout reporting meets cancellation. The seven day snapshot contains two commits on main, dated October 10 and October 12, 2026. For engineers exposing data through subscriptions, the useful detail is what happens when a response remains unread and the subscription is cancelled.

The October 10 fix to stop subscription timeout sends after cancellation targets a narrow lifecycle problem. A subscription can reach its timeout while delivery of an error is still pending. If the consumer has stopped reading, cancellation must let that pending work finish. Otherwise, reporting the timeout can itself become work that never completes.

The production file touched is internal/exec/subscribe.go. The commit subject identifies the intended behavior, while the accompanying regression test names the scenario explicitly: TestSchemaSubscribe_CancelWhileTimeoutErrorPending. This is a useful distinction for operators. The change concerns a pending timeout response at cancellation, rather than a general promise about subscription throughput or query execution speed.

For a service that exposes pipeline progress or incoming records through GraphQL subscriptions, this is a cleanup concern. Those are application examples, not integrations added by these commits. A timeout message has value only while a consumer can receive it. Once the subscription is cancelled, completing cleanup takes precedence over waiting indefinitely to deliver that message. Applications still need to cancel abandoned subscriptions; the library fix addresses how timeout reporting responds to that cancellation. The supplied excerpt does not establish the exact production implementation, so it would be premature to attribute the fix to a particular channel or select arrangement.

The test excerpt deliberately leaves the first response unread with _ = responses. It then waits on <-entered, waits again through the test synchronization mechanism, and calls cancel(). That order is the important part of the reproducer. It puts cancellation after the test has reached a coordinated point, with response consumption intentionally absent.

subscription_test.go appears in both commits, making it the most frequently touched file in this small activity window. The test focuses on a consumer that does not drain the response stream. A test that continuously reads responses would exercise a different condition: the timeout response could have a willing receiver. Leaving the response unread keeps the delivery problem present when cancellation happens.

This scenario is worth carrying into application testing when GraphQL subscriptions sit in front of a data pipeline. As a separate integration check, stop consuming responses, cancel the subscription, and verify that the application’s subscription work terminates. Keep any assertion about upstream readers separate. A GraphQL execution fix does not establish that a database cursor, broker consumer, or application goroutine also obeys cancellation. The visible excerpt supports the library scenario; it does not demonstrate cleanup across a complete ingestion service.

The October 12 test change replaces the timeout sleep with synctest.Wait(). Previously, the visible sequence used time.Sleep(2 * time.Second) between receiving from entered and calling cancel(). The new line uses the test’s synchronization facility at the same point. The unread response and cancellation call remain in place in the supplied diff.

That is a small edit with a clear testing purpose. A fixed sleep expresses a duration and relies on the test reaching the intended state within that interval. An explicit synchronization call expresses coordination with the concurrent work under test. In this regression, the ordering matters because cancelling too early could miss the pending timeout condition entirely. The follow up strengthens how the test reaches that condition without changing the scenario it is meant to cover.

There is no benchmark in the activity snapshot. Removing a two second sleep is not enough evidence to claim that CI becomes two seconds faster, particularly without inspecting the surrounding test execution. Nor does this test edit imply a production latency improvement. The useful outcome is a more deliberate regression test around cancellation timing. The production behavior change belongs to the earlier fix.

  • Track when the cancellation fix reaches the version your service actually uses. This snapshot describes activity on main; it does not identify a release tag containing the change.
  • Check subscription shutdown with an unread response in your own integration tests. Observe application cleanup as well as GraphQL completion, especially where a subscription owns an upstream reader.
  • Keep performance claims separate from this fix. The available evidence concerns timeout delivery and test synchronization, with no measured throughput, memory, or latency results.