@eintrek/erp-shell 0.1.36 → 0.1.38

package/dist/index.js

@@ -382,7 +382,22 @@ function useInvalidateQueriesOnOrgChange(organizationId) {
         // still hit the invalidate path below.
         if (wasEmpty)
             return;
-        queryClient.invalidateQueries();
+        // Remove, not invalidate.
+        //
+        // invalidateQueries marks entries stale and refetches the mounted ones,
+        // which leaves the previous organisation's rows sitting in the cache and
+        // on screen until a refetch lands. Any query whose key does not carry the
+        // organisation — and the request is scoped by the X-Organization-ID
+        // header, so most keys have no reason to — then reads as a cache hit for
+        // the new organisation and renders the old one's data under the new
+        // one's name. A colleague found /O26000021/employee showing three
+        // employees belonging to O26000033, with the breadcrumb and the title
+        // both correct.
+        //
+        // Dropping the entries costs a loading state after every switch, which is
+        // the honest thing to show: nothing fetched under one tenant is worth
+        // keeping once the tenant changes.
+        queryClient.removeQueries();
     }, [organizationId, queryClient]);
 }
 /**
@@ -1893,7 +1908,19 @@ instance.interceptors.request.use(async (config) => {
     if (token) {
         config.headers.Authorization = `Bearer ${token}`;
     }
-    const organizationId = getOrgFromCookie() || getOrganizationId();
+    // localStorage first, cookie second.
+    //
+    // Both are written by the same state machine, but not at the same moment:
+    // setOrganizationId writes localStorage synchronously and then awaits a
+    // server action for the cookie. Preferring the cookie meant every request
+    // fired during that round trip carried the previous organisation — while
+    // the query params, built from React state, already carried the new one.
+    //
+    // The backend scopes by this header and ignores organization_id in the
+    // query, so those requests asked for organisation A and were handed B, and
+    // the answer landed in the cache under A's key. No amount of cache clearing
+    // reaches that: the entry is wrong, not stale.
+    const organizationId = getOrganizationId() || getOrgFromCookie();
     if (organizationId) {
         config.headers["X-Organization-ID"] = organizationId;
     }