api: share dashboard and list aggregates across replicas through a short Redis cache
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- go, redis
- Domain
- backend, distributed-systems
Research direction
Start by reading test/load/BASELINE.md and tracing CountDagsByLatestRunState to find the dashboard aggregate query and its callers. Then inspect how the project separates Lite and Pro deployments and handles Redis and per-key request deduplication. Done means 50 concurrent dashboard pollers trigger at most one aggregate query per key per TTL, responses are no more than TTL seconds stale, database failures remain usable, and individual run or task state is never cached.
Written by the indexing model from the issue text.
Description
Why
CountDagsByLatestRunState costs 453 ms on the 1M run data set (test/load/BASELINE.md), and every open UI tab repeats it on the auto refresh interval, on the same primary the scheduler uses. This is the cache half of #2331.
What
- Cache dashboard aggregates per tenant and per filter in Redis with a TTL of a few seconds, below the UI refresh interval.
singleflightper replica, so a burst of tabs costs one query per key per replica at most, and one per key cluster wide while the value is fresh.- Fail open to the database; Lite uses an in-process TTL cache with the same interface.
- Never cache anything a user acts on (the state of a single run or task).
Done when
With 50 concurrent dashboard pollers the primary sees at most one aggregate query per key per TTL, and responses are at most TTL seconds stale.
Generated by Claude Code
- Dominant language
- Go
- Stars
- 46
- Forks
- 1
- Avg merge
- 10h 26m
- Merged PRs (30d)
- 606
Getting set up
- Ships a Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from dexadata/dexaflow
-
area/docs documentation priority/p3
Difficulty 1/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
Maintainers usually reply within 1 day
-
CI is red on mainOpenci-red
Difficulty 4/5 3-5 days Newbie friendliness 38/100
Maintainers usually reply within 1 day
-
area/storage enhancement priority/p3
Difficulty 4/5 3-5 days Newbie friendliness 43/100
Maintainers usually reply within 1 day
-
redis: support Sentinel and Cluster, and set explicit client timeoutsPossibly taken @neochaotic claimed this 1 day ago. Openarea/config area/storage enhancement priority/p2
Difficulty 5/5 Over a week Newbie friendliness 38/100
Maintainers usually reply within 1 day
All issues in dexadata/dexaflow
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
[Bug] K8s reconcile still resets explicit 0 to defaults for response_api, memory and flow statePossibly taken @Bevisy claimed this today. Openneeds-acceptance
Difficulty 2/5 1-3 hours Newbie friendliness 87/100
vllm-project/semantic-router#5998 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
devantler-tech/ksail#8256 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
Maintainers usually reply within 1 day
-
desktop v3 windows
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
esengine/DeepSeek-Reasonix#15016 · 1 comment ·
Maintainers usually reply within 1 day