Why does the Web SDK load the wrong Application Code when navigating between subdomains?

The Pushwoosh Web SDK caches its configuration, including the applicationCode, in an IndexedDB database named PUSHWOOSH_SDK_STORE (in its keyValue object store). It is not stored under a localStorage key of that name.

When this actually happens

Browser storage is scoped per origin (scheme + host + port). Separate subdomains such as app1.example.com and app2.example.com are different origins and therefore never share this cache. You hit the wrong-Application-Code problem when two different Application Codes are initialized on the same origin — for example example.com/site-a and example.com/site-b, or after you change the Application Code on an existing site. In that case the SDK reads the previously cached configuration and initializes with the old code.

Solution

Delete the cached IndexedDB database before initializing with a different Application Code. Note that localStorage.removeItem('PUSHWOOSH_SDK_STORE') has no effect — the key does not exist there.

// Clear the cached SDK state (IndexedDB, not localStorage)
await new Promise((resolve) => {
    const request = indexedDB.deleteDatabase('PUSHWOOSH_SDK_STORE');
    request.onsuccess = request.onerror = request.onblocked = () => resolve();
});

// Initialize with the correct Application Code
pushwoosh.push(['init', {
    applicationCode: 'YOUR_CORRECT_APP_CODE',
    // ... other parameters
}]);

Because deleteDatabase is blocked while another tab still holds the database open, also unregister any stale Pushwoosh service worker for that scope, then reload the page.

The cleanest long-term fix is to give each application its own origin (a distinct subdomain), so their SDK caches, service worker scopes and push subscriptions stay independent.