Running RQ-dashboard-fast in containerized services/K8S

[naomatheus]

Hey @Hannes221
I wanted to open a discussion about something. I appreciate fast_rq quite a lot as its created the observability I've been looking for.
One issue is giving me an idea and I wonder if you've thought about this before. One issue I'm having now is that when I'm running my fast rq dashboard in a separate service than the service connected to redis, then I run into import module issues.

Situation is: I run redis, redis-dashboard, and fastapi in separate services in my architecture. The main fastapi service uses the redis cache, uses the redis connection for queueing, and has its own internal module logic.

The problem arises when redis-dashboard tries to use the Job attributes, in effect calling methods/attributes on the Job. Since the Job in this context is happening in completely different context, non of the modules involved in processing that Job are accessible to the service running the dashboard.

I can think of some work arounds for this non-observability of successful jobs when in a microservice/containerized architecture, and may be able to contribute. But just curious if you've run into this issue already?

One thing that does work is Failed jobs report their status. Because I'm assuming the Failed jobs only need to access the ID and traceback from Redis, but they do not need to access or call attributes on the Job to know its status or get internal analytics or logging from the Job or Worker.

[Hannes221]

Hey @naomatheus!

Thank you for bringing up this topic and starting this discussion.

I haven't encountered the problem for myself, but I think I understand the mentioned limitations. What would be your ideas to solve this problem? I have some ideas too, but would be interested in your ideas.

[naomatheus]

How does the Fail status report? It seems like it just grabs the Trace output from the Redis cache where the failure output is written.
Can the same be done for successes?
It seems like right now at least, the rq dashboard wants to access the Job object itself to get the attributes of a successful job. But if the Job exists in different context, it can't load modules that are used/implicated in the Job. Rather than figuring out how to pass the sub modules of a Job to the RQ dashboard, maybe there can be a way to grab JSON traces from the Success status as well.

So in this case, fastrq dashboard looks for what it can find in the Redis cache, and does not need to call any attributes on the Job.

What do you think of that concept?

I haven't dug into it thoroughly yet, but wanted to see if you had already encountered this. I can think more about it as well.

@Hannes221