More responsive tag caching

[saikonen]

Currently the MFGUI backend holds an in-memory cache of available tags for runs due to these being very heavy to query a unique set of on deployments with large amounts of runs. The cache is invalidated once every 5 minutes, making the list of tags sometimes stale.

This is especially apparent when a Flow is executed for the first time with a unique set of tags. It takes the cache TTL for the new tags to be available for filtering purposes

Goals

• Verify the issue on a local setup
• Propose a solution for keeping the tag cache as up-to-date as possible, without a performance penalty.

Instructions

This issue is meant to be a venue for asking further questions on the topic. Implementation details and proposals are to be kept separate.

When you have met the goals of the issue, it is time to show and tell.
You can do this for example with your own fork with an issue or pull request and messaging a mentor on Slack with a link.

[rahulgunwanistudy-2005]

Hi! Here's my proposed approach for this issue.

The codebase already has a real-time event pipeline...
ListenNotify picks up pg_notify events and broadcasts them via a shared AsyncIOEventEmitter. Every major component (Websocket, RunHeartbeatMonitor, etc.) is wired into it, except AutoCompleteApi.

The fix:

1. Pass the shared event_emitter into AutoCompleteApi in ui_server.py
2. In notify.py, emit a run-insert event when a run INSERT is detected
3. In autocomplete.py, listen for run-insert and immediately call the existing update_cached_tags() instead of waiting for the 5-minute sleep cycle
4. Add a short debounce (~10s) to avoid hammering the DB if many runs are created at once

The periodic loop stays as a fallback. update_cached_tags() is unchanged.

Happy to hear if this looks right before I open a PR!

[rawadhossain]

Hey @saikonen, I explored this issue and implemented a fix based on the existing setup.

What I did:

• Reproduced the issue locally using a minimal test_flow.py that runs with a unique tag
• Verified that immediately after the run finishes, /tags/autocomplete returns an empty data array
• Confirmed through logs that run INSERT notifications are emitted but AutoCompleteApi was not reacting to them

AutoCompleteApi was the only component not subscribed to the shared event_emitter. Its cache was updated by periodic_tags_fetch_and_cache().

Fix approach:
Emit a run.created event on run INSERT and subscribe to it in AutoCompleteApi, scheduling a debounced refresh of the cached tags while keeping the periodic refresh as a fallback.

Implementation + verification (before/after results) are in this PR: #13

[Aryan95614]

The GIN index on (tags || system_tags) from PR #10 could help with the initial cache population query. If the cache refresh uses a tag aggregation query, having that index avoids a seq scan on large tables. Happy to dig in if this overlaps with the filtering work.