Skip to content

Conversation

alepane21
Copy link
Contributor

This PR introduces hooks inside the subscription lifecycle. We also decided to remove old pubsub implementation that is already deprecated and the router is not using anymore.

@coderabbitai summary

Checklist

  • I have discussed my proposed changes in an issue and have received approval to proceed.
  • I have followed the coding standards of the project.
  • Tests or benchmarks have been added or updated.

alepane21 and others added 30 commits July 18, 2025 18:56
…resolve at the initialization of each client subscription
…ce to fix when a subscription is completed while a hook is still sending messages)
…tarthandler' into ale/eng-7600-add-subscriptiononstarthandler
Copy link
Contributor

coderabbitai bot commented Oct 6, 2025

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.


Comment @coderabbitai help to get the list of available commands and usage tips.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Tests**
* Enhanced subscription-related test coverage for the GraphQL data
source, aligning test utilities with current interfaces to improve
reliability and maintainability.
* Validated subscribe/unsubscribe and update flows under various
scenarios to reduce brittleness and increase confidence in behavior.
* Performed minor cleanup in test code to improve readability without
altering functionality.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

## Checklist

- [ ] I have discussed my proposed changes in an issue and have received
approval to proceed.
- [ ] I have followed the coding standards of the project.
- [ ] Tests or benchmarks have been added or updated.

Implements missing methods to satisfy the `resolve.SubscriptionUpdater`
interface, so tests can build. Since these methods are not used by the
tests, they are empty. There tests in place already in resolve_test.go,
which test wether the updater can manage subscriptions individually, so
I did not add any.
@coderabbitai summary

## Checklist

- [ ] I have discussed my proposed changes in an issue and have received
approval to proceed.
- [ ] I have followed the coding standards of the project.
- [ ] Tests or benchmarks have been added or updated.

I adjusted two tests which are failing during Githubs CI run:

```
--- FAIL: TestResolver_ResolveGraphQLSubscription (31.69s)
    --- FAIL: TestResolver_ResolveGraphQLSubscription/SubscriptionOnStart_ctx_updater_only_updates_the_right_subscription (0.01s)
        resolve_test.go:5604: 
            	Error Trace:	/home/runner/work/graphql-go-tools/graphql-go-tools/v2/pkg/engine/resolve/resolve_test.go:5604
            	Error:      	Should be true
            	Test:       	TestResolver_ResolveGraphQLSubscription/SubscriptionOnStart_ctx_updater_only_updates_the_right_subscription
    --- FAIL: TestResolver_ResolveGraphQLSubscription/SubscriptionOnStart_ctx_updater_on_multiple_subscriptions_with_same_trigger_works (0.01s)
        resolve_test.go:5674: 
            	Error Trace:	/home/runner/work/graphql-go-tools/graphql-go-tools/v2/pkg/engine/resolve/resolve_test.go:5674
            	Error:      	should not be here
            	Test:       	TestResolver_ResolveGraphQLSubscription/SubscriptionOnStart_ctx_updater_on_multiple_subscriptions_with_same_trigger_works
FAIL
```

These tests work locally, at least on my machine. I assumed it only
manifests itself on slower CPU´s like it's the case on Github workers.
After testing around with some time.Sleeps() here and there, I found
that if messages in tests are not emitted fast enough, then heartbeat
messages might find their way into the recorders message list. As these
tests have nothing to do with heartbeat testing I disabled them here. I
am not 100% sure this is the problem, but I am fairly certain and I
think it makes sense anyway.
@coderabbitai summary

## Checklist

- [x] I have discussed my proposed changes in an issue and have received
approval to proceed.
- [x] I have followed the coding standards of the project.
- [x] Tests or benchmarks have been added or updated.

# Context

Some notes first:
- Its only happening for tests introduced on the cosmo streams topic
branch
- It seems to be a race condition in tests rather than actual engine
code

I spotted two tests failing on Github Actions due to race conditions.
They work locally and are CPU timings related.

Those two tests are
- test 1 `SubscriptionOnStart ctx updater only updates the right
subscription`
- test 2 `SubscriptionOnStart ctx updater on multiple subscriptions with
same trigger works`

### test 1:
There is a race condition going on. Here is the output of the test on
Github runners with engine logs enabled.
```
resolver:trigger:subscription:add:17241709254077376921:1
resolver:create:trigger:17241709254077376921
resolver:trigger:start:17241709254077376921
resolver:subscription_updater:update:17241709254077376921
resolver:trigger:initialized:17241709254077376921
resolver:subscription_updater:update:17241709254077376921
resolver:trigger:subscription:update:17241709254077376921:1,1
resolver:trigger:update:17241709254077376921
resolver:trigger:subscription:add:17241709254077376921:2
resolver:trigger:subscription:added:17241709254077376921:2
resolver:trigger:subscription:update:1
resolver:trigger:subscription:flushed:1
resolver:trigger:subscription:update:1
resolver:trigger:subscription:flushed:1
resolver:trigger:started:17241709254077376921
resolver:subscription_updater:complete:17241709254077376921
resolver:subscription_updater:complete:sent_event:17241709254077376921
resolver:trigger:complete:17241709254077376921
resolver:trigger:complete:17241709254077376921
resolver:trigger:subscription:closed:17241709254077376921:1
resolver:trigger:subscription:closed:17241709254077376921:2

recorder 1 messages: [{"data":{"counter":1000}} {"data":{"counter":0}}]
recorder 2 messages: []
```

As you can see recorder 2 misses its one expected message. The reason is
that we update the trigger with the counter=0 message (line 8) before
the second subscriber is added (line 9). So it misses the message. This
happens because in the test we don't wait for the subscriber to finish
registration on the trigger before sending the counter=0 message. Now we
actually wait for that.

### test 2:
Kind of the same error. Here is the engine debug output from a failing
Github Actions run:

```
resolver:trigger:subscription:add:15889878720417707388:1
resolver:create:trigger:15889878720417707388
resolver:trigger:start:15889878720417707388
resolver:subscription_updater:update:15889878720417707388
resolver:trigger:initialized:15889878720417707388
resolver:subscription_updater:update:15889878720417707388
resolver:trigger:subscription:update:15889878720417707388:1,1
resolver:trigger:update:15889878720417707388
resolver:trigger:subscription:add:15889878720417707388:2
resolver:trigger:subscription:added:15889878720417707388:2
resolver:subscription_updater:update:15889878720417707388
resolver:trigger:subscription:update:15889878720417707388:1,2
resolver:trigger:subscription:update:2
resolver:trigger:started:15889878720417707388
resolver:trigger:subscription:update:1
resolver:trigger:subscription:flushed:2
resolver:trigger:subscription:flushed:1
resolver:trigger:subscription:update:1
resolver:trigger:subscription:flushed:1
resolver:subscription_updater:complete:15889878720417707388
resolver:subscription_updater:complete:sent_event:15889878720417707388
resolver:trigger:complete:15889878720417707388
resolver:trigger:complete:15889878720417707388
resolver:trigger:subscription:closed:15889878720417707388:1
resolver:trigger:subscription:closed:15889878720417707388:2

recorder 1 messages: [{"data":{"counter":1000}} {"data":{"counter":0}}]
recorder 2 messages: [{"data":{"counter":1000}}]
```

As you can see recorder 2 misses the counter=0 message. Both are
expected to have the same messages in the same order. Both recorders
have the counter=1000 message, which is delivered via
subscription-on-start hook but recorder 2 misses the counter=0 message,
delivered via fake stream. The count=0 message is delivered (line 8)
before recorder 2 is subscribed (line 9). This happens because in this
test, like in the other, we don't wait for the recorders to finish
subscribing to the trigger, and sending off the counter=0 messages via
fake stream early. Its fixed by waiting for a complete subscription.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants