[🐞] $instanceId$ not found (e.g., 22fejj73w43 not found) error when multiple tabs/pages are open

[techfg]

Describe the bug

When multiple tabs/pages are open within a browser (same window or separate), attempts to access the main thread encounter $instanceId$ not found errors (e.g., 22fejj73w43 not found in prod build, Error finding instance "2dab62yogpr.d" on window 2 in debug build)

Note

This only appears to occur when using service workers, when atomics are used, the problem does not seem to occur.

Reproduction

Repo: https:/techfg/partytown/tree/add-multiple-pages-tests
PR: #493

Steps to reproduce

To reproduce the issue, either manual or automated testing can be performed. To prepare:

1. Clone https:/techfg/partytown
2. Checkout branch add-multiple-pages-tests
3. npm install
4. npm run build

Manual Testing

Any test that accesses the main thread after initial page load will reproduce the issue (e.g., Platform - Event, Error, History, Multiple Pages, Window, etc. / Integration - Event Forwarding, Facebook Pixel, Google Tag Manager, etc.).

To run the tests manually:

1. npm run serve
2. Close all browser windows to ensure no pages are loaded
3. Open a new browser window
4. Navigate to a test page and open developer tools to view console messages
5. Open a new tab, navigate to the same test page and open developer tools
6. Navigate back to first page and manually run the applicable test. For example, when running the Event test, click the 'inc'
7. Repeat steps 2 - 7 for each manual test to ensure clean environment since once a page/tab is broken, it will never recover

Expected Result: The test behaves as expected visually and no errors in the console of either tab/page

Actual Result; The test does not complete the expected outcome and error messages are visible in either one (or both) of the consoles of the open pages.

Automated Testing

Six (6) new tests have been added to automate the testing of multiple tabs/pages:

Note

For the gtm & facebook-pixel test, the problem does not reliably reproduce when following the open page, wait, open page, wait, act on page 1, act on page 2 sequence of steps. Running manually, these steps reproduce the issue every time. The automated test takes a slightly different sequence of steps which seems to reliably reproduce the issue.
 

• Integrations
  1. integration event forwarding multiple tabs
  2. facebook-pixel multiple tabs
  3. gtm multiple tabs
• Platform
  1. events multiple tabs
  2. multiple pages
  3. window multiple tabs

To run the automated tests:

1. npm run test

Expected Result: All tests pass

Actual Result: 6 tests fail

  6 failed
    [chromium] › tests/integrations/event-forwarding/event-forwarding.spec.ts:38:1 › integration event forwarding multiple tabs 
    [chromium] › tests/integrations/facebook-pixel/facebook-pixel.spec.ts:27:1 › facebook-pixel multiple tabs 
    [chromium] › tests/integrations/gtm/gtm.spec.ts:27:1 › gtm multiple tabs =======================
    [chromium] › tests/platform/event/event.spec.ts:67:1 › events multiple tabs ====================
    [chromium] › tests/platform/multiple-pages/multiple-pages.spec.ts:3:1 › multiple pages =========
    [chromium] › tests/platform/window/window.spec.ts:163:1 › window multiple tabs =================

Browser Info

Reproduced on Chrome, Firefox & Edge (didn't test others)

Additional Information

In the GTM test, the custom event button-click does not appear to fire a GA4 tag so no event is sent to GA. While this doesn't impact the tests directly, it may be helpful to update the GTM container to define a tag that fires on the custom event button-click to ensure a full cycle occurs when the button in the test is clicked.

[hoebbelsB]

Hey @techfg as we read this, we switched to atomics in a customer project and still see those kind of errors. It is somehow related to analytics.js. Also some of the /collect requests from analytics are pending forever with partytown enabled, which results in errors thrown and missing tracking information. They do work fine without partytown. Mostly those instanceid errors are happening at very similar times when the collect calls fail. Maybe there is a connection

[techfg]

Hi @hoebbelsB -

Thanks for the insight. It's very possible that there are multiple issues going on, some in core partytown with very simple scenarios (similar to the tests I added in #493) and others related to more complex scenarios like GTM. For example, depending on your GTM configuration, there may be things like custom scripts, third-party scripts, etc. loaded that could lead to other issues/scenarios. For sure, the $instanceId$ not found occurs without GTM involved.

Regarding atomics, I'll admit that I didn't do extensive testing to see if I could trigger the $instanceId$ issue but based on the testing I did do, at least without GTM, I was unable to reproduce the problem.

This may be a situation where the low hanging fruit issues (from #493) get addressed, and then the next layer of issues are tackled.

Couple of questions:

1. Do you see the problems when only a single browser window/tab are open or only when multiple window/tabs are open?
2. Are you able to simplify your GTM configuration to possibly narrow down what triggers the issue in your case?

[hoebbelsB]

hey @techfg thanks for the fast reply.

About the failing collect calls, here is how it should look like (when partytown is disabled)

This is the result when partytown is enabled.

First, the requests aren't of type ping anymore, but of type fetch. Second, they are pending forever and partytown throws errors.

This specific problem is visible all the time and sadly we are not able to change configurations on the gtm setup itself. We have to deal with what is there. But it all boils down to analytics, so no other 3rd party involved here.

The instanceId error seems to only appear when multiple tabs are involved, though I couldn't even reproduce it once while testing this morning.

Sorry for the squishy information, hope it's still helpful

[hoebbelsB]

now I was able to reproduce the instanceId not found error, 2 tabs are open on the same page

[hoebbelsB]

even more occurrences, only 1 window & atomics in use

[techfg]

Hi @hoebbelsB -

Based on what I've been seeing, once you encounter the $instanceId$ not found errors, nothing further seems to work so would be interesting to know what the first console error is. If you are able to reproduce this with a single window, then more than likely its a separate/different issue from what I've been seeing in my situation and what's represented in the tests in #493.

As it pertains to GTM, since you aren't always able to reproduce the issue consistently, it could be something with a certain interaction/tag firing that is having issues. Without knowledge of your GTM, difficult to say for certain and although there may not be any third-party scripts, if you have any custom HTML that contains javascript, or utilize any GTM community templates, etc. there could be something in there. Also, if you have a Content Security Policy (CSP), the switch to atomics likely will require adjustments to that. If there is any way for you to copy your GTM container and then start stripping away pieces, you may be able to find something that way.

The best advice I can give is to enable Partytown debugging and log all calls and then dig through the output to see if you can identify anything. From there and based on what you've shared thus far, while I can't be certain, I'm guessing your issue is different than the root cause of the issue I posted here in which case, would be best to create a new issue with an isolated repro.

In meantime, hopefully this issue can get addressed as it will only help in your scenario whether or not its the same or different issue.

[hoebbelsB]

hey @techfg thanks for the input. We've already activated logging for everything. Unfortunately it's not easy to debug as the error messages are not very insightful.

Do you have any idea about the hanging network requests I've posted earlier?

[techfg]

Hi @hoebbelsB -

Yeah, debugging is a challenge :( Regarding the hanging network requests, my guess is that the first thing that goes wrong is the $instanceId$ errors and once that occurs, all bets are off and subsequent activities will all fail so the hanging is likely a byproduct of the $instanceId$ errors. Do you see the hanging before you see the $instanceId$ errors? Also, in the scenario were you reproduce with multiple tabs/browsers, make sure to check the console of all windows/tabs as you will likely see errors in all of them (or at least multiple of them).

One last thought is if you have any internal links on your site that use target=_blank - this will open a new tab to your site which would introduce the multiple window/tab scenario.

[hoebbelsB]

For me it felt more like it's the other way around. First those requests fail, after some time also the instanceId errors appear. It's also entirely possible those two are not connected at all.

[techfg]

Yeah, could be related to each other or separate but based on what you've described, why I think your issue(s) might be a different than the issue I posted here. What's the first error you see in the console?

[hoebbelsB]

We are running into those hanging requests by guarantee on certain interactions. Mostly connected to soft navigations, routing in an SPA. It's an angular app. So the fetch errors are mostly the ones who are raised first

[techfg]

Long shot but it seems you are using Google Universal Analytics (analytics.js) which was retired in July 2023 (unless you are on a commercial plan I think). That library hasn't been maintained I don't believe so possibly migrating to GA4 might be helpful. Again, total long shot, just thinking out loud. Either way, since everything works without PT, it should work with PT but there could be something in analytics.js that PT hasn't implemented a proxy for.

[hoebbelsB]

you are right, this project is using the deprecated analytics.js. Some of the requests to the very same endpoint, from the very same script is failing. It doesn't look like missing support. Yeah, moving to ga4 is planned, but won't happen soon.

Is it possible to exclude analytics from partytown somehow?

[hoebbelsB]

adding analytics.js to the loadScriptsOnMainThread option makes it completely disabled. It doesn't do anything afterwards. And still I can see failing requests from GA4, even if UA was "disabled"

[techfg]

loadScriptsonMainThread would be the way to move analytics.js to the main thread but given the way gtm.js & analytics.js interact, this is unlikely to work. The reason is likely that they "talk" to each other and now you have gtm.js on worker and it has no way to talk back to analytics.js. You would need to look in to mainWindowAccessors and build them in after reverse engineering what you would need to provide.

If this is blocking a go-live, would recommend that you just keep all of GTM on main thread. From there, would recommend you find a way to copy your GTM container and then strip back functionality until you can identify which piece of it is causing the issue. Once you have that, since you're able to reproduce this with a single tab which means its different than the problem identified in this issue, hopefully you can create an isolated repro and log a new issue in this repro with the details.

[tibineagu]

Unfortunately I think this might still be happening.

Please check out tibineagu/partytown-instance-error - it's using 0.10.1 which should include the fix.

I tried to keep the repro as simple as possible. The proxied function simply gets and sets from localStorage.

As soon as another tab is open, the errors start popping up again.

---

EDIT:

I was wrong.