Hea 752/dagster graph ql api is intermittently failing with a protocol error when accessed via the revproxy django view #176
Conversation
…ebsocket connections see HEA-752
…y-failing-with-a-ProtocolError-when-accessed-via-the-revproxy-Django-view
…y-failing-with-a-ProtocolError-when-accessed-via-the-revproxy-Django-view
|
@girum-air I get INFO messages in my local environment that say We also have some debug messages: And some very freqyent info messages: And some possible problem views: and |
…ith-a-ProtocolError-when-accessed-via-the-revproxy-Django-view' of github.com-work2:FEWS-NET/HEA-Database-Development into HEA-752/Dagster-GraphQL-API-is-intermittently-failing-with-a-ProtocolError-when-accessed-via-the-revproxy-Django-view
|
@rhunwicks I think the first two issues are just more info logs by the web socket and revproxy view, we can supress them. The connection pool filling issue seem requiring us increasing the max pool size. But the 3rd warning realted to the StreamingHttpResponse, I think require an aync support by the view which seems a more involved change I couldn't get to make it work, but can we ignore that for now as it is warning only? |
apps/common/apps.py
Outdated
| name = "common" | ||
| verbose_name = _("common") | ||
|
|
||
| def ready(self): |
There was a problem hiding this comment.
This seems very non-standard.
My reading around this is that it's not an error, even if we would get better performance if we increased the pool max_size.
Do we know if the message is caused by the regular proxy or by the websockets one?
I am tempted to suppress the log message, but otherwise leave it all alone for now. Perhaps we start a new MR based on the original one, but without these commits.
hea/settings/base.py
Outdated
| "urllib3": {"handlers": ["console", "logfile"], "level": "INFO", "propagate": False}, | ||
| "common.models": {"handlers": ["console", "logfile"], "level": "INFO", "propagate": False}, | ||
| "common.signals": {"handlers": ["console", "logfile"], "level": "INFO", "propagate": False}, | ||
| "uvicorn.error": {"handlers": ["console"], "level": "WARNING", "propagate": False}, |
There was a problem hiding this comment.
I am not sure that we want to lose all INFO messages. Just the overly chatty ones.
Would this be better using a custom logging filter to suppress specific messages?
We need to be certain that the logger is still capturing regular new page requests.
|
I agree we can ignore the StreamingRequest for now. |
…y-failing-with-a-ProtocolError-when-accessed-via-the-revproxy-Django-view
|
@girum-air how can we tell from the Chrome DevTools that the GraphQL query is using a websocket rather than a regular request? Do we have debug logging in our consumer or elsewhere that lets us see what code is coming via channels vs a regular http request? Is there a setting in Dagster that controls whether it uses websockets or http polling for the GraphQL queries? |
…y-failing-with-a-ProtocolError-when-accessed-via-the-revproxy-Django-view
Yes @rhunwicks under
Yes, we have in the Consumer class, when connection happens e.g.:
Yes there is, |
…y-failing-with-a-ProtocolError-when-accessed-via-the-revproxy-Django-view
…/Dagster-GraphQL-API-is-intermittently-failing-with-a-ProtocolError-when-accessed-via-the-revproxy-Django-view Hea 752/dagster graph ql api is intermittently failing with a protocol error when accessed via the revproxy django view
No description provided.