Support schema extensions for subsctriptions - Alternative

[kristjanvalur]

Subscriptions are now executed like queries and mutations, and extension hooks are called.
Result extension hooks are called for each result yielded by the subscription

Note, This is a separate PR from #2784, because it contains an alternative, less intrusive, way to do this.
It avoids changing the signature of schema.subscribe which now, like graphql-core, continues to return either
an ExcecutionResult or an AsyncGenerator.

Description

the Schema.subscribe(), when awaited returns a Union[ExeuctionResult, AsyncGenerator[ExecutionResult,None]].
This is similar to before, but previously it would return a raw GraphQLExecutionResult object, or an AsyncIterator over said type, directly from graphql-core.

Internally, an AsyncGenerator is created which yields an extra initial result, which is either a ExecutionResult in case
the inner subscribe method failed and no iterator is forthcoming, or a None if subscription is about to proceed. An
outer method examines this initially yielded value and either returns that to the caller, or the already started AsyncGenerator, which the caller then continues to iterate from, maintaining all context which that iterator had already established.

Tests are added to tests for result extensions.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Documentation

Issues Fixed or Closed by This PR

• Extenstions support for subscriptions. #2097

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as we

[codecov]

Codecov Report

Merging #2825 (14a83ba) into main (6d86d1c) will increase coverage by 0.00%.
The diff coverage is 98.04%.

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #2825    +/-   ##
========================================
  Coverage   96.55%   96.55%            
========================================
  Files         468      468            
  Lines       29201    29417   +216     
  Branches     3592     3616    +24     
========================================
+ Hits        28194    28403   +209     
- Misses        827      831     +4     
- Partials      180      183     +3     

[botberry]

Thanks for adding the RELEASE.md file!

Here's a preview of the changelog:

---

Subscriptions now support Schema Extensions.

---

Here's the preview release card for twitter:

Here's the tweet text:

🆕 Release (next) is out! Thanks to @kristjanvalur for the PR 👏

Get it here 👉 https://github.com/strawberry-graphql/strawberry/releases/tag/(next)

[codspeed-hq]

CodSpeed Performance Report

Merging #2825 will degrade performances by 79.84%

_{Comparing mainframeindustries:kristjan/subscription-extenstions-2 (14a83ba) with main (6d86d1c)}

Summary

❌ 1 regressions
✅ 10 untouched benchmarks

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Benchmarks breakdown

	Benchmark	main	mainframeindustries:kristjan/subscription-extenstions-2	Change
❌	test_subscription	232.7 ms	1,154.1 ms	-79.84%

[patrick91]

/pre-release

[botberry]

Pre-release

👋

Releasing commit [cb3949a] to PyPi as pre-release! 📦

[botberry]

Pre-release

👋

Pre-release 0.196.0.dev.1689676980 [cb3949a] has been released on PyPi! 🚀
You can try it by doing:

poetry add strawberry-graphql==0.196.0.dev.1689676980

[kristjanvalur]

Performance regression is expected when all of the schema extension boilerplate code is added on top of a trivial method.
I suspect that if we add a performance test which tests iterating over 1000 entries of a subscription, that will perform much more favourably