Support websockets and redirect python stdout to the socket #56
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've opened this as a separate PR to the main server development stuff.
The main thread works fine, but when you call out to it from the CLI you don't see any of the internal python logging (see #51). Not the end of the world but it does make for a pretty poor UX when calling the server from our lovely CLI.
The plan then is to use a websocket instead of a regular post to the service, and have the websocket stream results down. So the server now supports a HTTP or WS interface and you can connect to any service with either one. This all works great.
The Difficulty
The problem is that python's stdout, although it'll be displayed in the server's log stream, doesn't appear in bun's stdout. So when python says
print()
, it goes to a different stream than bunsstdout
stream. Which means bun cannot trap it to send into the websocket.This is a bit if a bummer. Without redirection support from
node-calls-python
, it means we have to use a child process to get the stdout. And even if we did that we might have to run some filters on the stdout, or find a way to make sure we're capturing the logs for the right job.Solution
My solution, which is pretty nasty, is to redirect python logs to file and read that file back into node.
It goes like this:
The worst bit of the solution is that the only way I've found to read the log back into node is this:
Yep, I'm spawning a child process anyway.
Failed Attempts
The solution is probably the dumbest and worst solution I could fine. But it kinda works.
Here are other things I tried:
node-calls-python
has no means of sending an IPC message between the python thread and the main thread. I suspect there's a way to do this but I don't think the maintainer has any interest and I do not have the knowledge.node-calls-python
), I could do$`tail -f file.log`
. But that also has no streaming interface - you have to await it, and of coursetail -f
won't return the promise.Bit frustrating really.
Issues
Well, if this works we can close:
#55 #51
Further Work
We could probably release this when done... but I think there is a high chance that logs will interfere if two services happen to be running concurrently.
But I'd rather add either (a) a very simple blocking queue or (b) plug in workerpool and ensure each python context only runs one thing at a time.
I don't think b) is a huge amount of work and probably would need doing anyway at some stage.