[RESEARCH]: Should there be an API method for running a task to completion?

[AlexPykavy]

At the time of writing this, the current implementation of the worker's StartTask waits till completion. But it's planned to change it in the #7.

Now the question: should we keep possibility to run a task to completion via a dedicated endpoint or passing some additional argument like ?wait=true in the request? Probably, the answer to that question will depend on another one: what are side effects of keeping many (probably long) connections on the worker's side?

[AlexPykavy]

Here is what ChatGPT answered:

⚠️ Side Effects of Keeping Many (Long-Lived) Connections on the API Side

Keeping many (especially long-lived) connections on the API side can introduce several performance, reliability, and scalability issues. Here’s a breakdown:

---

🔧 1. Resource Exhaustion

• File descriptors/sockets: Each open connection uses a file descriptor; the system has limits (ulimit).
• Memory usage: Buffers, session state, or context per connection consume memory.
• Threads: Thread-per-connection models may consume too many threads, leading to memory and CPU pressure.

---

⚙️ 2. Scalability Limits

• Without async I/O or event loops, the system won’t scale well.
• Blocking operations (like synchronous I/O) tie up resources unnecessarily.

---

🐌 3. Increased Latency

• High resource contention (CPU, memory, I/O) can slow down response times.
• Languages with garbage collection (like Java) may suffer performance spikes.

---

🔥 4. Risk of Denial of Service (DoS)

• Too many long-lived connections can exhaust limits and block new clients.
• Even if unintentional, this resembles a DoS attack.

---

🧰 5. Load Balancer/Proxy Issues

• Load balancers also have connection limits.
• Long-lived connections can cause:
  • Imbalanced traffic distribution
  • Idle connection buildup
  • Timeout or dropped connections

---

🧼 6. Connection Leaks

• Poorly managed connections may not close properly (e.g. client drops).
• Over time, this can leak resources and degrade performance.

---

📊 7. Monitoring & Troubleshooting Complexity

• High volume and duration make it hard to track connection health.
• You may see "zombie" connections that appear alive but do nothing.

---

🔍 When Are Long Connections Justified?

Long-lived connections are often necessary for:

• WebSockets / SSE (Server-Sent Events)
• HTTP/2 multiplexing
• gRPC streaming
• Real-time apps (chat, trading platforms, live notifications)

But even then, manage them carefully with:

• Connection pooling
• Idle timeouts
• Health checks / keep-alives
• Async, event-driven I/O

---

✅ Mitigation Tips

• Use async frameworks (FastAPI, Node.js, Go).
• Set idle and max lifetime timeouts.
• Monitor socket count, memory, and CPU usage.
• Implement connection pooling when possible.
• Autoscale horizontally to handle more connections.

---

🛠️ Tip: Tailor your solution to your stack. Let me know if you want suggestions for specific tech (e.g., Python, Node.js, Java, etc.)