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

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

[d19dotca]

@girish just wanted to ask about an update on this one.

[girish]

@d19dotca will try this again...

[girish]

Out of curiosity, is anyone else seeing this behavior?

[Meuschke]

@girish It seems that this behavior happens for me too.
This seems to be browser independent. Restarting the Umami application then helps.

[girish]

I tried to reproduce this but I am not able to. Here's what I did:

• Install umami
• Add domain in umami.
• Install surfer
• Put tracking code from umami into a sample index.html
• I refresh index.html 10 times. I see 10 in umami

Is there something special I need to do?

[stefano]

Try restarting either Umami or rebooting the server, after that Umami should stop working (you will see an error in the browser's console when loading the site).
Then after restarting/rebooting again, it will work again.

Basically it stops working every other reboot, so when a reboot is needed I need to reboot twice to get Umami to work.

Not sure if it matters, but in my case the website I am tracking is on a different server than Umami.