`TaskiqAdminMiddleware` adds significant latency to task triggering

[nimaxin]

The TaskiqAdminMiddleware significantly slows down task triggering (.kiq()) because it blocks execution waiting for HTTP requests to complete. Each task operation creates a new HTTP client httpx.AsyncClient() instead of reusing one, adding unnecessary overhead.

The middleware should:

1. Avoid blocking task operations while reporting status
2. Reuse HTTP connections where possible httpx.AsyncClient()
3. Handle reporting asynchronously without impacting task throughput

This becomes particularly noticeable when triggering many tasks rapidly (e.g., in loops or batch operations). The current implementation forces sequential HTTP requests, making bulk task triggering much slower than expected.

I believe the problem is clear, but I'm happy to provide code examples or additional details if needed.

[nimaxin]

Just wanted to add one more point: Instead of reporting task status via HTTP, a better pattern might be to publish task events to the message broker (e.g., Redis/RabbitMQ) and have the admin service consume them asynchronously. This avoids blocking tasks on network requests and removes the per-task overhead of HTTP entirely.

This is actually how Celery and Flower handle monitoring:

• Celery workers emit task events (e.g., task-started, task-succeeded) directly to the broker.
• Flower subscribes to these events in real-time without workers needing to make HTTP calls.

Adopting a similar event-driven approach would likely scale much better—especially under heavy load or in batch-processing scenarios—while keeping the system decoupled and efficient.

[spikeninja]

Hey! Thank you for such comprehensive description of the issue
Yes, we are aware of this problem and will fix it asap

Let's then do this in 2 steps: firstly we will get rid of the overhead that middleware provides in the current version, and then we will see how can we implement event-based flower-like approach.