> How does this work when ... there is no sticky sessions in place (because hot spots on certain upstreams kinda defeats the purpose of a load balancer), and th

> How does this work when ... there is no sticky sessions in place (because hot spots on certain upstreams kinda defeats the purpose of a load balancer), and the user that kicked off that async pdf job on PID 1, inside container 1, refreshes their browser and is now connecting to container 2, which is running a different Linux process than where the pdf task is running in a thread? The user destroys their first liveview instance and gets a new liveview instance. You may not have properly set up bidirectional links so the destruction of this first liveview kills the first background job, or it may run to completion and be discarded. This might be exactly the semantics the user wants. If the user expects state to stick around that would need to be implemented separately. > If you have to background the pdf generation, it’s slow. If it’s slow to generate a document, it’s large. I'm not sure it's quite that slow. It's too slow to freeze the entire UI while it generates. But it's fast enough blocking a http response until it finishes often works. A simple system for transient background processing like Task.async might be appropriate. > Disks and file systems are for passing very large messages on a system We don't know what the type of the response message is. It could well be a filename in a temporary dirextory. That would be the simplest way to implement a background task that shells out.