Sam Santi
Sam Santi
I'm using subscriptions via [graphql-ws]. See example: https://github.com/rshk/yawc/ Messages are forwarded to subscriptions via a Redis PUB/SUB (this allows scaling to >1 app/websocket server). [graphql-ws]: https://github.com/graphql-python/graphql-ws **HOWEVER**, I'm still having...
Looks like this does the trick: https://github.com/rshk/yawc/commit/95d6e50a87f83f37eb5d97a7ba9143ace8870e5f (It will basically make all subscriptions listen from the same Observable, so it definitely stops countless Redis connections from being created / never...
Ok, just managed to get it to work with Apollo. The problem lies with incorrect handling of the multipart-encoded request, here: https://github.com/graphql-python/flask-graphql/blob/master/flask_graphql/graphqlview.py#L126-L127 I sub-classed the GraphQLView to properly handle ``multipart/form-data``,...
See #51
It was behaving slightly differently in my case ([Gatsby](https://www.gatsbyjs.org/) website), in that the callback was only getting called if landing on the form from another page, not if accessing the...
Btw, can I ask pretty please people finding this issue in the future to just click the "thumbs up" on the issue description, instead of commenting with just a `+1`?
I'm interested to hear your use cases about this..? About skipping commits from the queue if a newer one is scheduled to be deployed, I'm not sure I'd want that,...
About rollbacks, it might be worth requiring some extra flag to explicitly say "I know I'm about to deploy an older version, this is exactly what I want, go ahead"?...
About reverts: as they usually means something bad happened already, I'm not really sure I'd like to have anything magic going on; maybe the safest option would be to just...
> [Future] Blacklist SHAs to ensure that a check (i.e. build system) being valid doesn't have to mean the commit is safe Maybe just creating a "status" on github associated...