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

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://github.com/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://github.com/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.

About this issue

  • Original URL
  • State: closed
  • Created 8 months ago
  • Reactions: 2
  • Comments: 16 (15 by maintainers)

Commits related to this issue

Most upvoted comments

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.

~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.