Closed crankynetman closed 3 weeks ago
You can reproduce this by loading the example-orchestrator GUI, then adding a new fixed input to the Node product in the example-orchestrator, then reloading the example with docker compose down -v && docker compose up -d
, and finally going to the GUI and clicking on the New Subscription
dropdown. You won't see the new product until you clear your cache for the page.
@crankynetman, from your description I would expect a page refresh should also update the New subscription
dropdown?
We could add a cache invalidation to update the dropdown, would that be a solution?
IIRC it actually required a "hard refresh" and a normal refresh didn't actually update the list. I'm not too sure of all the mechanics involved that make this list show up though, so I can't quite comment, but if we just pulled that list of product types fresh every time, that seems pretty low-risk to me as I can't see that causing much of an increase in load to the backend. Or perhaps just when websockets re-connect after a backend restart we could invalidate that cache somehow, as querying the DB every time you load the dropdown does seem a little silly.
We will discuss this with the developers, first signals are that it not too much work.
BE ticket needed, for both task and WF dropdown.
This needs to be fixed in the frontend, we should not cache the dropdown for selecting a new product.
The call takes only 200ms, let's refresh the list in FE when clicking on the button.
Latest proposal. Add a development flag that turns of all caching so all queries are always refetched.
When you add a new product type (or add a new fixed input to a product) it doesn't show up automatically in the frontend
New Subscription
dropdown until you clear your cache. We should probably make sure that this is fetched automatically without user intervention.