#Issues running Convex Python client behind Docker

15 messages · Page 1 of 1 (latest)

severe phoenix
#

I'm running into an interesting issue while trying to utilize the Python sdk on a simple Flask application running on Gunicorn behind Docker.

First off, the application works perfectly fine when not behind Docker. Usage of the sdk is fine. However the moment I set the application up behind Docker, any requests using the sdk suddenly timeout and I just get a stacktrace pointing to the sdk function called.

Looking through the docs for the sdk I noticed that there are technically 2 client objects, a websocket based one and an http one, my guess is I'm not exposing whatever port the websocket is trying to communicate through as the http client appears to work fine.

My devops knowledge is a little rusty; is there a way to get which port I need to open? Port 80 and 443 are open already.

Or is there another trick to working with Docker? I don't mind using the http client but given that it's mentioned as being "Legacy", it'd be nice to move onto the newer class.

(as a side note, it might be good to remove the set_debug mention in the readme; unless it's somewhere else I missed, I got an error saying the method doesn't exist on ConvexClient )

Thank you.

marble kernelBOT
#

Thanks for posting in #1088161997662724167.
Reminder: If you have a Convex Pro account, use the Convex Dashboard to file support tickets.

    - Provide context: What are you trying to achieve, what is the end-user interaction, what are you seeing? (full error message, command output, etc.)
    - Use [search.convex.dev](https://search.convex.dev) to search Docs, Stack, and Discord all at once.
    - Additionally, you can post your questions in the Convex Community's #1228095053885476985 channel to receive a response from AI.
    - Avoid tagging staff unless specifically instructed.

    Thank you!
hard flint
#

That's interesting. Using the websocket client shouldn't require exposing any port (the http client doesn't either; it's only running servers in docker that need to expose ports). I'll try to repro. Could you share your dockerfile? The websocket client uses different dependencies, so I'm curious if one of those isn't working from inside docker

hard flint
#

I was not able to repro. my steps:

  1. docker run -it python:3.9
  2. pip install convex
  3. run a file like this:
import convex
from convex import ConvexClient
client = ConvexClient("https://doting-bird-25.convex.cloud")
for message in client.subscribe("readingList:get"):
  print(message)

and it works & stays subscribed through the websocket

severe phoenix
#

Hey Lee, thanks for the quick response and the sample; yea, I'm a bit stumped myself; your conclusion was pretty much mine and I thought things should just operate on whatever ports are already open but 🤷‍♂️

Didn't see your message in time to provide a sample myself, but I'll experiment in a little bit(need more coffee) and try to test things out again and report back.

severe phoenix
#

Hey @hard flint , looking more at this now and your test, did you happen to try behind a server as well? I wonder if that might be the differentiating factor between our two tests, I'm looking to run things on a Flask/Gunicorn server behind Docker.

In any case, I tried again combining your test with a very barebones representation of what I'm trying to run and uploaded that here

https://gitlab.com/sortofsleepy/convex-test

tldr' it kinda worked? It worked at least once or twice, which made me think my db setup was the issue but after more testing the requests started to fail more often; even then for the successful tests, it still took quite awhile for the request to complete.

hard flint
#

i think that repo is private. i'll try a flask repo

severe phoenix
#

Sorry about that, should be public now

hard flint
#

i made a flask app and it works for me

#

oh yeah i see why your code doesn't work

# 
@app.route('/')
def root():
    for message in client.subscribe("readingList:get"):
        print(message)

    # idea is that we should see text if the request went through
    return "working?"

the loop never exits, because it stays subscribed to the query and keeps waiting for more changes

#

do you perhaps want client.query ?

severe phoenix
#

Ah, interesting. I guess I'll try another sample at some point, I was just trying to integrate your initial test here.

That said I'm pretty sure I did try client.query (as that's what I'm doing in the app I'm trying to run) but I believe it also failed. Let me double check

#

Yea, same result, also times out.
This is what I tried

@app.route("/")
def root():
  data = client.query("links:get")
  return "working?"

(links:get is just supposed to fetch data from a table)

hard flint