Arda TANRIKULU

Thanks for the PR! There is also another open PR related to this; https://github.com/ardatan/graphql-tools/pull/6896

It is a breaking change because we use the existing package's options directly. We hold it until a new major release.

Mock package generates a schema, so we can't know when the execution starts and ends. It is the execution's responsibility so your solution is good enough.

First of all, thank you for creating the issue! It would be great if we can get some bare minimum setup that reproduces the issue because we have different test...

You don't need to add `YogaInitialContext` to `createYoga`. On the other hand, first generic is `ServerContext`, the second is `UserContext`; https://github.com/graphql-hive/graphql-yoga/blob/main/packages/graphql-yoga/src/server.ts#L744 Also you can learn the difference between these two...

I don't think it is possible and accurate. https://the-guild.dev/graphql/hive/docs/gateway/other-features/performance/response-caching#overall-comparison We have this kind of comparison that shows why we use ETag instead of Cache-Control header. TTL-based invalidation prevents us to...

It doesn't look accurate to return `Cache-Control` header with the calculated TTL as an option. Not sure if it is a good idea to have this kind of "broken" option...

Actually it is exposed with `onTtl` https://github.com/graphql-hive/envelop/blob/main/packages/plugins/response-cache/src/plugin.ts#L152

Yes ```ts const ttlByRequest = new WeakMap(); // In the response cache parameters useResponseCache({ // other options... onTtl({ ttl, context }) { if (ttl != null && ttl > 0)...

Like I said earlier, I am not sure if I am fan of supporting a broken behavior. I'll keep this open so we can discuss here with others. cc @enisdenjo...