A Saved Supplier Connection Appears on the Next Request
When a system says something is saved and the user cannot find it a moment later, trust suffers more than from an error.
After a new supplier connection was saved, the Lookout job form could leave it out of the supplier list for minutes, until a full page reload. A save now reaches every layer, including the browser cache, the server’s response cache and the cached company and user records, so the next request already sees the new connection.
The saved notice has just faded. An operator switches to Lookout to set up a price comparison and wants to include the supplier connection that was just added, but the dropdown does not list it. A page reload later, there it is. Nothing reported an error, which is exactly what makes it unsettling: did the save fail, or was it misread?
The cause was not one place but a chain of caches. The browser kept the supplier list for ten minutes. The server cached the same endpoint’s response per user. Company and user records each had a cache of their own, which used to be cleared before the data had been fully written and could then be refilled with old values. Any layer left out meant the new connection showed up minutes late.
A save now carries the change through every layer. After a supplier connection is created, updated, linked or deleted, the portal clears its own supplier list; the server’s clean-up after a write reaches per-user cached reads; and the company and user record caches are cleared again once the data has been fully written. Cache lifetimes were not shortened, because that would only hide the problem inside a smaller window.
In the test environment, the new connection appeared in the dropdown on the next request after saving, without a page reload, for platform and tenant accounts alike. The caches are all still there, so the supplier list still loads quickly, and deleting a connection goes through the same clean-up in the portal and on the server.