Benedikt Franke

> I don't think we need a lighthouse:clear-query-cache command Agreed, let's not add an extra command. I think it makes sense for `lighthouse:clear-cache` to clear all caches that Lighthouse knows...

> The command will be inconsistent: in some cases it will delete query cache and in others it won't. We can document this behaviour. > Also people might use tagging...

Looking through the commit history, I found that this setting was ignored since mid-2019. The need for this appears to be very slim, so I am reformulating this issue as...

> protect the app from username enumeration I think this has nothing to do with batched queries. > denial of service attacks Those are somewhat related, but I reckon you...

@stayallive opened the PR to see the results of the test run.

That's a tricky one. We currently store the internal value of the `ENUM` when serializing the subscription, which causes the rehydrated execution during the broadcast to fail. This might also...

@stayallive a tricky part is that the raw request may contain literal argument values as well as variables. We don't ever see an intermediary representation where those are merged, but...

The generated types in https://github.com/nuwave/lighthouse/blob/master/src/Pagination/PaginationManipulator.php would have to change and https://github.com/nuwave/lighthouse/blob/master/src/Pagination/PaginationServiceProvider.php would have to add the interface to the schema.

I am all over the `graphql-php` codebase, mostly working on strict typing and uncovering/fixing bugs. Have not paid particular attention to async execution. Your assumption seems sound, I think it...

We could add a method to field middleware directives to determine if it is required to be added to a given field and run this during schema compilation.