torchbox / wagtail-grapple

A Wagtail app that makes building GraphQL endpoints a breeze!
https://wagtail-grapple.readthedocs.io/en/latest/
Other
151 stars 57 forks source link

Problem using subscriptions #50

Open IAmNatch opened 4 years ago

IAmNatch commented 4 years ago

Hi there,

I'm trying not to bog down the repo with issues, but have also exhausted all other avenues. Once I've gotten a working demo together I'll put it online, and as well commit to help update some of the documentation around avoiding pitfalls.

Currently, when I query a page using a token, it correctly renders the draft. However, when I add the subscribe keyword, I receive the following error:

{
  "errors": [
    {
      "message": "Subscriptions are not allowed. You will need to either use the subscribe function or pass allow_subscriptions=True"
    }
  ],
  "data": null
}

My query looks like this:

subscription {
  page(id: 3, token: "id=3:1jCCKp:I7_EYqlnQkflxoRXfTbVuPG_yJA") {
    ... on HomePage {
      title
      paragraph
    }
  }
}

There is no other stacktrace. I'm currently using path("", include(grapple_urls)) as my graphQL provider, with the following versions:

graphene-django==2.8.2
wagtail==2.8
wagtail-grapple==0.4.11
wagtail-headless-preview==0.1.4

Any help would be greatly appreciated.

IAmNatch commented 4 years ago

I have three additional pieces of information that might be helpful.

One: The error message above is displayed at the '/graphql' endpoint. If I try to use the same query on the '/graphiql' endpoint, I receive a similar yet different error message:

"Your subscription data will appear here after server publication!"

Two: My Django setup is running in docker. Is there a specific port that subscriptions rely on that I should be opening?

Three: I receive the following message on my logs every few moments when I'm browsing graphiql: django_1 | 172.26.0.1 - - [13/Mar/2020 15:03:49] "GET /subscriptions HTTP/1.1" 301 -

IAmNatch commented 4 years ago

Okay I was able to make some progress. Sorry to bombard but I figure more info is better than less.

I realized my development server was running with runserver_plus which I've learned is not compatible with WS. I moved back to regular runserver, and in doing so have resolved part of the issue.

Now, the /subscriptions endpoint no longer receives 301, I can connect to WS via websocat internally in my docker container, and externally via https://www.websocket.org/echo.html over ws://localhost:8000/subscriptions.

I can see connect and disconnect successfully in my logs, and as well I can send a payload like:

{"hello": "world"}

and receive back a proper error message:

RECEIVED: {"type": "error", "payload": {"message": "Invalid message type: None."}}

Despite this, I am still encountering the same error messages ("after publication" and "subscriptions are not allowed") when attempting to subscribe on graphiql over either endpoint.

Looking forward to discussing this further and getting to the bottom of it, I hope this info is helpful for others in the future.

IAmNatch commented 4 years ago

@NathHorrigan I hope all is well with your team despite all that's going on in the world.

I'm wondering if you've ever experienced anything like the above issue and if you have any hints as to where I should be looking. Thanks a lot!

NathHorrigan commented 4 years ago

Hi there!

Sorry for the lack of support recently, My schedule has been jam-packed. I will take a closer look at the weekend.

Have a great week!

IAmNatch commented 4 years ago

Thanks for the quick reply! No worries at all. I've only been so diligent as I'm really excited about all the great work you've been doing lately and would love to incorporate it further into my workflow. I appreciate all the support and contribution to this wonderful community.

IAmNatch commented 4 years ago

Hey there! Here's a build log with more info that may be useful.

Based on the install instructions I don't beleive I'm supposed to specific any versions but maybe it would be better if I pinned certain dependancies? Happy to jump on a chat as well.

ERROR: daphne 1.4.2 has requirement asgiref~=1.1, but you'll have asgiref 3.2.7 which is incompatible.
ERROR: channels 1.1.8 has requirement asgiref~=1.1, but you'll have asgiref 3.2.7 which is incompatible.
ERROR: asgi-redis 1.4.3 has requirement asgiref~=1.1.2, but you'll have asgiref 3.2.7 which is incompatible.
ERROR: asgi-redis 1.4.3 has requirement redis~=2.10.6, but you'll have redis 3.4.1 which is incompatible.
ERROR: wagtail-grapple 0.4.11 has requirement Django<2.3,>=2.2, but you'll have django 3.0.4 which is incompatible.
ERROR: wagtail-grapple 0.4.11 has requirement graphene-django==2.7.1, but you'll have graphene-django 2.9.0 which is incompatible.
ERROR: wagtail-grapple 0.4.11 has requirement graphql-core==2.2.1, but you'll have graphql-core 2.3.1 which is incompatible.
ERROR: wagtail-grapple 0.4.11 has requirement wagtail<2.8,>=2.5, but you'll have wagtail 2.8 which is incompatible.
tbrlpld commented 4 years ago

I ran into the same error message ("Subscriptions are not allowed. You will need to either use the subscribe function or pass allow_subscriptions=True"). I do not have a docker container in the mix and use the normal runserver.

tbrlpld commented 4 years ago

I have tried searching for similar issues, couldn't really find anything. I saw some comments somewhere (sorry I lost the source 😅) that pointed out that the GraphiQL interface is not able to work with subscriptions. Because of that I have tried to create a subscription with the Altair client (which I think was used in the demo gif) but still no success. The Altair client does not show an error, but just does nothing... which is also not very encouraging.

@NathHorrigan have you had any time to look into this? Can you reproduce the issue or are subscriptions working fine for you?

tbrlpld commented 4 years ago

Another thing that seems different for me from the docs is the cookies. I do not see any cookies used-token being placed on the "Admin" page or the "Preview page.

To extract the token I have to click "Preview" in the Admin, then in the new tab open the developer console (which at this point is still empty), then I have to refresh the page or go back to the Admin and click the "Preview" button again. Now the developer console of the Preview tab shows the send requests and I can extract the token from the request send to http://localhost:8001/preview (see screenshot).

image

Still, no used-token cookie is placed in either the admin or the preview tab. That I am accepting cookies is checked by the csrftoken and sessionid cookies being present.

zerolab commented 4 years ago

The used-token cookie is set in https://github.com/torchbox/wagtail-headless-preview/blob/0d89fb2e4140d6eaabe62e0a7428424c9e848c3c/wagtail_headless_preview/models.py#L122 (and is dependent on setting HEADLESS_PREVIEW_LIVE = True)

Would you be able to check that bit? I suspect the docs need updating

zerolab commented 4 years ago

Ah, https://github.com/GrappleGQL/wagtail-grapple/blob/abdaded1862c781923529431fd2ee946a5f264f3/docs/general-usage/preview.rst#L64 does mention HEADLESS_PREVIEW_LIVE = True 🤔

tbrlpld commented 4 years ago

@zerolab Yes, I have that option set. I am using the project in the /example directory of the Grapple repo for testing.

Even with HEADLESS_PREVIEW_LIVE = True I do not see the used-token cookie in neither admin nor preview tab. I am checking the cookies with the Firefox Developer Console.

Admin

image

Preview

image

I have just double checked and I also am not getting the cookie in Chrome. So it does not seem to be a Firefox issue.

Are you able to reproduce this issue or is the cookie set for you?

Another question is if the cookie not being set is connected to the subscription issue or if this should be a separate thread (possible on the wagtail-headless-preview repo).

IAmNatch commented 3 years ago

@tbrlpld Did you ever resolve this issue? Live preview is such an important feature, I'd love to get it up and running.

tbrlpld commented 3 years ago

Hi @IAmNatch No, I have not resolved the issue. I am actually happy so far with the normal preview. When I wrote the above comments I had not tried the normal preview because the docs seemed to suggest that all preview needs the subscriptions to work. Once I noticed that preview works, but only the live update part is not working I basically stopped working on the issue with the subscriptions.

I did create issue #81 saying that the docs should be updated to point out the difference between preview and live preview. I still plan on proposing an update to the docs, but haven't gotten around to it yet.

IAmNatch commented 3 years ago

@tbrlpld That makes sense. I've also gotten regular preview working, but live preview is such a killer feature in my mind, it's definitely something I'd like to resolve. Looking at wagtail-headless-preview I think you're right that it may be related to the lack of cookies- To test that I'll need to run this package locally as well. I'll report back next weekend when I can tinker a while longer.

MateuszMielniczuk commented 2 years ago

@IAmNatch @tbrlpld as far as I understand, to use normal preview there is need to write .html template and use jinja? So there will be 2 pages one on front-end site and second on Wagtail. And with any change on front page we need to change it also on Wagtail?

Is there any progress on subscriptions or any clue how to fix it? I was trying to implement that on 0.12.0 release and documentation with no success. I have same problems like described above. I was trying Altair client with no responses and graphiql interface I only got message: "Your subscription data will appear here after server publication!"

tbrlpld commented 2 years ago

@MateuszMielniczuk No, you don't need separate Django or Jinja template. That would be quite the waste.

You will need https://pypi.org/project/wagtail-headless-preview/ on the backend and the headless frontend needs to be setup to work with that. If you are using Gatsby for the frontend, you can use https://github.com/GrappleGQL/gatsby-source-wagtail to enable preview.

dopry commented 1 year ago

I played with live preview using the latest wagtail_headless_preview. You can check out my fix/live-preview-subscriptions to see what I'm working on.

As far as I can tell in wagtail_headless_prevew.models.HeadlessPreviewMixin.serve_preview, use_live_preview is never true, even when ?live_preview=true is passed to the endpoint, which means the signal that triggers the subscription update is never sent.