Umami 2.2.0 tracker XHR request works only on every second app restart

[girish]

@d19dotca I checked your setup and I see a 404 atleast. I don't get the alternate success/fail that you noticed.

The issue as seen above is that there is a double .js when querying the tracker script.

[girish]

I found that there is a bug in the 3.0.0 migration. I have revoked that one and now published 3.0.0-1. Also, the tracking code changes if you set TRACKER_SCRIPT_NAME .

It was:

<script async defer data-website-id="ef7b2b31-017e-401b-bcd7-cdd3ff35a5c6" src="https://umami.domain.com/umami2.js.js"></script>

But, after updating, it became:

<script async src="https://umami.domain.com/umami2.js" data-website-id="ef7b2b31-017e-401b-bcd7-cdd3ff35a5c6"></script>

Notice that it had .js.js before but only one .js now.

[d19dotca]

@girish thank you Girish! Is it safe to simply update then or do I need to go back to 1.x before going to 2.2?

[robi]

@girish hmm it also had a defer directive, and now it doesn't.

[girish]

@d19dotca The migration did not complete with the previous package. so, it's best to go back to 1.x and then go again to 2.2.

On a side note: if you don't have much setup, I recommend just starting afresh with 2.2 actually. I am not sure about the quality of the migration scripts.

[d19dotca]

@girish is it possible to deploy the latest image on top of the existing one and force an upgrade? It seems like the easier way to go for those who already updated so data isn’t lost. When I check for updates it doesn’t see the latest image though with the fix in it.

[girish]

@d19dotca so you are already on 3.0.0 or are you on 3.0.0-1 ? I am wondering how you ever upgaded because after upgrade from 2.x the login fails. Did that not happen in your case ?

[d19dotca]

@girish No, I never had any issues logging in. The package version shown in Cloudron for Umami is this one: is.umami.cloudronapp@3.1.0 (so it would seem neither of those image options).

[girish]

The package versions are:

• v2.4.2
• v3.0.0 - was revoked, had a migration issue
• v3.0.0-1
• v3.1.0 - this is the latest

so, you are at the latest already.

I assume you still have the problem ? I have no idea unfortunately what could be going wrong, we might have to ask upstream. Otherwise, depending on your setup, I simply suggest starting afresh. My understanding is umami 2 -> 3 nuked all historical event data anyways.

[d19dotca]

@girish Yes, I still see the issue, just tested again a few moments ago to confirm. If I restart the Umami app, the error is seen by all client sites. If I restart it again, suddenly it's fixed... until I restart it again. It's super strange.

I believe 3.1.0 was the only package available when I was able to get to upgrading the Umami app, is it possible there was maybe something that got skipped since I missed the 3.0.0 package version? I assume it should work fine if upgrading straight to 3.1.0 from 2.4.2 (assuming 2.4.2 was the pre-v2 Umami version).

@girish said in Umami 2.2.0 tracker XHR request works only on every second app restart:

Otherwise, depending on your setup, I simply suggest starting afresh. My understanding is umami 2 -> 3 nuked all historical event data anyways.

I've had this running for an about 4 months now, so I'd rather not lose all of that data. The Umami upgrade did not remove any of that data that I can see. Not sure if that's the correct expectation of the Umami upgrade, pretty sure it still keeps the data. I think the only thing it wasn't expected to bring forward to v2 was the event data (i.e. button clicks, etc) but that wasn't setup in mine so there were no event data anyways, just the regular page hits with metrics/data. Ref: https://umami.is/docs/migrate-v1-v2

[girish]

@d19dotca yes, that update route sounds plausible. We released 3.0.0-1 after 3.1.0 . Weird but this was because we found the issue in 3.0.0 later (when you reported this bug).

So, at this point, there is nothing to update for you. We also don't know why it seems to work only every restart. Maybe clone the app and see if it's reproducible in the cloned app. It's easier for us to debug then on the cloned instance.

[stefano]

I just did a fresh install of Umami a few days ago, on May 13th, and I am experiencing the same exact issue.

Initially everything works.
If I restart the app, then on the site it loads a 200 for the js file but a 400 for the XHR request (so the data is not logged).
If I restart the app again, it works again as expected.
And so on...

The only customization I have is in the env.sh where I added

export TRACKER_SCRIPT_NAME=get.js
export COLLECT_API_ENDPOINT=/api/get

The installed version is:

App Title and Version: Umami 2.2.0
Package Version: is.umami.cloudronapp@3.1.0

[jdaviescoates]

I recently updated (funnily enough also on 13 May). I don't really use it much so only just went to look and lo and behold, zero data has been captured since 13 May (I also note that contrary to the warnings, the old data seems to still be there).

I've just restarted the app to see if like others on this thread that somehow magically makes the data collection work again... didn't seem to.

[robi]

@jdaviescoates validate your tracker script still works and is being called correctly, or simply reinstall it with the new version with copy/pasta.

[stefano]

This issue persists and can't understand why it's happening.
Every time a reboot is required I need to remember to manually restart Umami, or it stops working.

So weird that it happens every other reboot/restart.

[d19dotca]

I agree, this is a bizarre issue and unfortunately I can't yet figure out where the issue is coming from.

[girish]

@stefano Is yours with a fresh install or migrated from Umami 1 ?

[stefano]

Fresh install. I installed Umami for the first time on May 13th.

The installed versions are:

App Title and Version: Umami 2.2.0
Package Version: is.umami.cloudronapp@3.1.0

[girish]

@stefano I missed your initial post about your setup. Do you see the same behavior with different browsers and ad block extensions disabled? I will try to reproduce this again in the meantime.

[stefano]

Ok, no worries

Yes, it doesn't depend on the browser. I tried with Chrome, Edge, Firefox and Brave (even with shields off), without any ad-blocking extension enabled.