As we’ve diagnosed the juju run-action and juju run deltas will be streamed via the AllWatcher to the pylibjuju client. This is by design, the pylibjuju client uses the deltas to work out when an action has been performed.
The underlying issue is the size of the payloads and the fact that they’re exceeding the max_size of a websocket frame. Upping the frame size should allow you to work around the problem short term (RFC-6455 states that a single WebSocket frame can be 2^63 bytes, so you’ve got a lot to play with).
The long term fix for this is to get your charm to save the action output of a given item to a location (s3, local file system) and perform a juju scp (if using local file system) to get that data.
Advanced
If you’re really sure you don’t want that data from a given action and I would strongly advise you don’t run this on a production server.
For all controller machines, SSH into them and run:
systemctl stop jujud-machine-*
Get access to mongo:
Then run the following, it will leave the actions in mongo, but clean out the results.
db.actions.updateMany({}, {$set: {"results": {} }})
Once you have run the database updates, you can then do:
systemctl start jujud-machine-*