Stats aren't updating to the current day in the background after the date changes

[designsimply]

Since I updated to Android 10 last week [Stats - Daily view in] the app doesn't automatically go to the current day. It only goes as far as the last day I opened the app from scratch. I updated to the latest version of the app (Feb, 2020) but still have the same issue.

You must close the app and reopen it in order for it to show the current day's site stats. Once you have reopened it, it does refresh the stats during the course of the day but will not automatically advance on the next day unless you close and reopen the app.

If I drag my finger downwards to update it does not go to the current date. It only shows me the dates up to the yesterday's date.

• Reported in 2761834-zen (internal reference)
• WordPress - 14.2 - Version code: 831
• Android device name: Samsung SM-N960U
• Site Type: Jetpack Free Plan

Additional recommended troubleshooting steps:

1. Verify that your blog and your device are both set to the same timezone.
2. If possible, please get a copy of your app logs from Account > Application log > copy icon (top right) and then send them to us in the app using the Contact Us form in the Account > Help & Support section of the app right after triggering the problem by doing a pull-to-refresh and seeing it fail for the Days Stats screen on a day you did not close and re-open the app since the previous day. It would be helpful to see if any relevant or helpful logs are generated and it needs to be just after triggering the problem and then copying the logs right afterward.
3. Please try going to Android Settings > Apps & notifications > WordPress app > Storage & cache and tapping the "Clear cache" option. Does the problem persist the next day?

Note: sounds very similar to the iOS issue at https://github.com/wordpress-mobile/WordPress-iOS/issues/12823. 🤔

h/t @erricgunawan for the original report. Thank you!

[rezzap]

The user has replied to confirm that clearing their cache options has fixed the issue. Shouldn't this be happening automatically on a re-install?

[erricgunawan]

The user is back on 2828761-zen:

I upgraded to version 14.4.1 a few weeks ago but it did not help. I see an update posted does not address the issue. Clearing the cache only works temporarily. The issue returns a day or two later.

I don't think they have sent a log yet, do we need to still ask it from them?

Is there anything else we can recommend, in the meantime?

[msilbers]

Apps have been provided in the ticket. The error that I see is included in this section:

21 - [Apr-02 24:14 API] Received response to Settings REST request. 22 - [Apr-02 24:14 STATS] 🔵 Tracked: stats_accessed, Properties: {"blog_id":155578055,"is_jetpack":true} 23 - [Apr-02 24:14 STATS] 🔵 Tracked: stats_period_accessed, Properties: {"granularity":"days","period":"days"} 24 - [Apr-02 24:14 SUPPORT] Zendesk push notifications successfully enabled! 25 - [Apr-02 24:14 API] Error fetching Jetpack settings: com.android.volley.ServerError 26 - [Apr-02 24:14 STATS] 🔵 Tracked: stats_overview_bar_chart_tapped, Properties: {"granularity":"days"}

@designsimply The user confirmed that clearing their device cache helped previously. Should this be happening automatically when reinstalling?

[designsimply]

The user confirmed that clearing their device cache helped previously. Should this be happening automatically when reinstalling?

Yes, a complete uninstall and reinstall for an app should clear the cache for that specific app.

To verify cache is cleared after a reinstall, I tried testing with a Pixel 3 Android 10 device and found that a complete uninstall and reinstall did clear the app cache in my test:

^{Tested with WPAndroid 14.6-rc-1 on Pixel 3 Android 10.}

Removing and re-adding an app will not clear the cache, and reinstalling from the Play Store (or updating) an app will not clear the cache. If something is happening with the cache that you didn't expect, you could try to help by explicitly asking for them to completely uninstall (not remove) and reinstall (not update) the app. Someone may just not have known there was a difference!

Is there anything else we can recommend, in the meantime?

Yes! You can double check the timezone with the user. It looks like someone asked about that but never got an answer. It seems they may just need to be reminded to check on that. Based on what I can see, I think the timezone settings for the site and device are probably the same but it would still be worth checking and making a note of it.

For this case, it might be helpful to ask for a screenshot of the Stats > Days screen when the problem happens. I would be interested to know if the graph has the current day and there's just not any data in it or if the current day is completely missing from the graph.

You could ask what they meant by "opened the app from scratch" in their first report—I'm actually not 100% sure what they meant by that, closed and reopened perhaps?

Another thing that is sometimes helpful to do is rewrite the report into a list of steps, this can sometimes help point out differences in what we might be thinking someone is doing and what they are actually doing. Writing out steps is also super super helpful to make it easier to dive in to testing for any given issue. To help, I've re-read the case and come up with the following testing steps (you could verify these and/or try testing them yourself tonight if you have an Android device—I can help too!).

1. Be on an Android 10 device.
2. Set the device timezone to New York.
3. If the WPAndroid app is open, close it.
4. Open the WPAndroid app.
5. Go to My Site > Settings and change the Timezone to New York.
6. Go to My Site > Stats > Days.
7. Leave the app open and leave the device overnight.
8. After a day has passed, reopen the app and go to My Site > Stats > Days.
9. Check to see if the graph shows the current day. In other words, is the current day completely missing from the graph or is the current day there and there's just not any data in it? Could you include a screenshot from this step? (Note: from the original report, it does sound like the current day is completely missing from the graph and that the app was left open in the background on the previous day. It would be good to verify this.)
10. If the stats are not showing the graph for the current day or if the current day is there but there's no data showing for it, try a pull-to-refresh and check to see if the stats update at that point.

Past that, the best possible things you can do to help for a case like this are:

1. Be able to replicate the problem and give clear steps to do so.
2. Find additional user reports of the same problem and add them to this thread.

[msilbers]

I am unable to reproduce this on Android 10, Samsung Galaxy Note 10. At Step 9, while the day in focus is still set to the previous day, today does show stats in the graph.

I've asked them to confirm their device and site timezone, asked for a screenshot of Stats > Days, and asked them to update the app again, to 14.5.

We may have another report though, waiting for details in 2884044-zen

[rezzap]

We do have a similar issue in 2884044-zen

The mobile devices and the site are all set to GMT+8.

The cleared the app cache and the problem remained.

They mention the only thing that works is "I then force stopped the app and started it again, and the date reset to today."

The app seems to post the current day's stats sometime between 9 and 11:30 am (GMT+8). Before that time, the previous day's stats show as the most current. I'm using Android 9. The app is the most current version.

Pulling down to refresh doesn't change anything.

I'm going to ask them for a screenshot.

Is there anything else we could suggest them to try here @designsimply ?

Thanks!

[rezzap]

A similar report of this found in 2980756-zen

The user notices the stats only update later in the afternoon.

• WordPress - 14.7.1 - Version code: 863
• Android device name: Samsung SM-G965U
• Site type Jetpack Personal plan.

They seem to think the timezone is matching, but I'm going to confirm this and if they tried clearing the cache. I'll also ask for logs.

[khaykov]

Stats are pretty complicated, so I wasn't able to pinpoint the issue. Maybe someone with more Stats knowledge, like @planarvoid could direct folks to the correct place to look at :)

[designsimply]

@rezzap I can't think of anything additional that would help the person from ticket 2884044. I do think continuing to look for additional cases and noting the following info for those will be helpful:

• App version
• Type of site
• Does pull-to-refresh have any effect?
• Does force closing and re-opening the app help?

@planarvoid I did notice that the user from ticket 2884044 said that pull-to-refresh does not update stats but that force stopping then re-opening the app does cause the stats to refresh, which is interesting, also all of the reports in this case so far are Jetpack sites. Should we be expecting the stats numbers in the app to match exactly with what we see on the web at all times? How often are stats expected to update in the app (real time, every hour, a few times a day)? Are Jetpack site stats expected to update at the same rate WP.com sites are updated?

[elibud]

@planarvoid can you please look into this one?

[designsimply]

The stats don't update. Today, May 13, the still show stats for May 11, even though I keep refreshing. I have to restart my phone if I want updated stats.

^{2-star review 5/13, 5:54 AM - WPAndroid 14.7 Samsung Galaxy S9+ Android 10}

[planarvoid]

I've looked into the method that loads the data for the Overview block (the block with the day columns) and I don't think there is any obvious issue. We're taking the current date and transforming it with the site timezone. I've tested this with a Jetpack site with extreme timezones and it seems to work correctly. On pull to refresh the forced flag is correctly passed and makes us skip the cache. As far as I see there is no issue in the app. It's possible there is some edge case I'm missing so I've added additional logging to see what actually happens when the user pulls to refresh. I'm still suspicious there is some caching on the endpoint that doesn't return correct data. Let's try to get the logs after the PR is merged to see what's happening.

[rossanafmenezes]

Another report here 3052710-Zen

User opens the app and the current day is not showing unless they close the app and open it again.

Version 14.9

Samsung SM-N960U

Self-Hosted connected via Jetpack version 8.6.1

[msilbers]

For the report just above:

• Pull to refresh did not help
• Clearing the device cache helped only for a day or 2
• timezone for site and device match

[zwarm]

@msilbers Could you ask the user to update to 15.1 then go to Stats > Days, pull-to-refresh the screen, and verify the problem is still happening? If it is, ask them to go to Account > Application log > copy icon (top right) and then send the logs in a reply on the help request, please? Thank you.

[msilbers]

This particular user (3052710-zen) says the problem is now resolved after updating to 15.1 and pulling to refresh. They checked for 4 days and have confirmed that it's working.

[azollafox]

We have another user reporting this issue is back on a WordPress.com Simple site for them, app version 15.9.1 ticket 3440642-zen

[bummytime]

@planarvoid @zwarm 👋 Did we get any logs that could help us determine if this is an endpoint caching or app issue?

[designsimply]

Another report came in from an app review saying Stats aren't updating:

Problems for a long time now that the app does not update dates when looking in the statistics. Must quit and restart it. The problem is back again.

• Device: Samsung Galaxy S10+
• Device language: Swedish
• App version code: 938
• App version name: 15.9.1
• Android version (SDK): Android 10 (SDK 29)

I asked them to please try going to Android Settings > Apps & notifications > WordPress app > Storage & cache and tapping the "Clear cache" option and to please report back if the problem persists the next day. If they do report back, I'll ask if it's possible for them to send in their logs.

[reginabally]

Sharing the app log in 3440642-zen.

WordPress - 15.9.1 - Version code: 938
Android device name: Samsung SM-G975F

01 - [Oct-27 18:45 UTILS] trackLastActivity, activityId: Notifications
02 - [Oct-27 18:45 API] Dispatching action: AccountAction-FETCH_ACCOUNT
03 - [Oct-27 18:45 READER] notifications update job service > job scheduled
04 - [Oct-27 18:45 READER] notifications update job service > job scheduled
05 - [Oct-27 18:45 API] WhatsNewStore: fetchWhatsNew
06 - [Oct-27 18:45 NOTIFS] notifications update job service > created
07 - [Oct-27 18:45 NOTIFS] notifications update job service > destroyed
08 - [Oct-27 18:45 NOTIFS] notifications update job service > created
09 - [Oct-27 18:45 API] Dispatching action: AccountAction-FETCHED_ACCOUNT
10 - [Oct-27 18:45 NOTIFS] notifications update service > completed
11 - [Oct-27 18:45 NOTIFS] notifications update job service > all tasks completed
12 - [Oct-27 18:45 NOTIFS] notifications update job service > destroyed
13 - [Oct-27 18:45 NOTIFS] Get settings action succeeded
14 - [Oct-27 18:45 UTILS] trackLastActivity, activityId: Notifications
15 - [Oct-27 18:45 API] Dispatching action: AccountAction-FETCH_ACCOUNT
16 - [Oct-27 18:45 READER] notifications update job service > job scheduled
17 - [Oct-27 18:45 READER] notifications update job service > job scheduled
18 - [Oct-27 18:45 API] WhatsNewStore: fetchWhatsNew
19 - [Oct-27 18:45 NOTIFS] notifications update job service > created
20 - [Oct-27 18:45 NOTIFS] notifications update job service > destroyed
21 - [Oct-27 18:45 NOTIFS] notifications update job service > created
22 - [Oct-27 18:45 API] Dispatching action: AccountAction-FETCHED_ACCOUNT
23 - [Oct-27 18:45 NOTIFS] notifications update service > completed
24 - [Oct-27 18:45 NOTIFS] notifications update job service > all tasks completed
25 - [Oct-27 18:45 NOTIFS] notifications update job service > destroyed
26 - [Oct-27 18:45 READER] notifications update job service > job scheduled
27 - [Oct-27 18:45 NOTIFS] notifications update job service > created
28 - [Oct-27 18:45 NOTIFS] notifications update service > completed
29 - [Oct-27 18:45 NOTIFS] notifications update job service > all tasks completed
30 - [Oct-27 18:45 NOTIFS] notifications update job service > destroyed
31 - [Oct-27 18:45 API] Dispatching action: SiteAction-FETCH_POST_FORMATS
32 - [Oct-27 18:45 API] Dispatching action: SiteAction-FETCH_SITE_EDITORS
33 - [Oct-27 18:45 UTILS] trackLastActivity, activityId: My Site
34 - [Oct-27 18:45 API] Received response to Settings REST request.
35 - [Oct-27 18:45 API] Dispatching action: SiteAction-FETCHED_POST_FORMATS
36 - [Oct-27 18:45 SETTINGS] Post formats successfully fetched!
37 - [Oct-27 18:45 SETTINGS] Post formats successfully fetched!
38 - [Oct-27 18:45 API] Received site Categories
39 - [Oct-27 18:45 API] Successfully fetched WP.com categories
40 - [Oct-27 18:45 API] Dispatching action: SiteAction-FETCHED_SITE_EDITORS
41 - [Oct-27 18:45 DB] Site found by (local) ID: 1
42 - [Oct-27 18:45 DB] Updating site: https://badlydrawnwolf.wordpress.com
43 - [Oct-27 18:45 UTILS] trackLastActivity, activityId: Help Screen
44 - [Oct-27 18:46 UTILS] trackLastActivity, activityId: Help Screen
45 - [Oct-27 18:46 API] Dispatching action: AccountAction-FETCH_SETTINGS
46 - [Oct-27 18:46 API] Dispatching action: AccountAction-FETCHED_SETTINGS
47 - [Oct-27 18:46 API] Dispatching action: WhatsNewAction-FETCH_CACHED_ANNOUNCEMENT
48 - [Oct-27 18:46 API] WhatsNewStore: fetchWhatsNew
49 - [Oct-27 18:46 API] Dispatching action: AccountAction-FETCH_SETTINGS
50 - [Oct-27 18:46 API] Dispatching action: WhatsNewAction-FETCH_REMOTE_ANNOUNCEMENT
51 - [Oct-27 18:46 API] WhatsNewStore: fetchWhatsNew
52 - [Oct-27 18:46 API] Dispatching action: AccountAction-FETCHED_SETTINGS
53 - [Oct-27 18:46 API] Dispatching action: AccountAction-FETCH_SETTINGS
54 - [Oct-27 18:46 API] Dispatching action: AccountAction-FETCHED_SETTINGS
55 - [Oct-27 18:46 API] Dispatching action: AccountAction-FETCH_SETTINGS
56 - [Oct-27 18:46 API] Dispatching action: AccountAction-FETCHED_SETTINGS
57 - [Oct-27 18:46 UTILS] trackLastActivity, activityId: Help Screen
58 - [Oct-27 18:47 UTILS] trackLastActivity, activityId: Help Screen
59 - [Oct-27 18:47 UTILS] trackLastActivity, activityId: My Site
60 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCH_ACCOUNT
61 - [Oct-27 18:47 API] WhatsNewStore: fetchWhatsNew
62 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCHED_ACCOUNT
63 - [Oct-27 18:47 UTILS] trackLastActivity, activityId: Site Picker
64 - [Oct-27 18:47 UTILS] trackLastActivity, activityId: My Site
65 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCH_ACCOUNT
66 - [Oct-27 18:47 API] WhatsNewStore: fetchWhatsNew
67 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCHED_ACCOUNT
68 - [Oct-27 18:47 API] Dispatching action: WhatsNewAction-FETCH_CACHED_ANNOUNCEMENT
69 - [Oct-27 18:47 API] WhatsNewStore: fetchWhatsNew
70 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCH_SETTINGS
71 - [Oct-27 18:47 API] Dispatching action: WhatsNewAction-FETCH_REMOTE_ANNOUNCEMENT
72 - [Oct-27 18:47 API] WhatsNewStore: fetchWhatsNew
73 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCHED_SETTINGS
74 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCH_SETTINGS
75 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCHED_SETTINGS
76 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCH_SETTINGS
77 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCHED_SETTINGS
78 - [Oct-27 18:47 API] Dispatching action: WhatsNewAction-FETCH_CACHED_ANNOUNCEMENT
79 - [Oct-27 18:47 API] WhatsNewStore: fetchWhatsNew
80 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCH_SETTINGS
81 - [Oct-27 18:47 API] Dispatching action: WhatsNewAction-FETCH_REMOTE_ANNOUNCEMENT
82 - [Oct-27 18:47 API] WhatsNewStore: fetchWhatsNew
83 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCHED_SETTINGS
84 - [Oct-27 18:47 UTILS] App goes to background
85 - [Oct-27 18:47 MAIN] ConnectionChangeReceiver successfully unregistered
86 - [Oct-27 18:47 UTILS] App comes from background
87 - [Oct-27 18:47 READER] notifications update job service > job scheduled
88 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCH_SETTINGS
89 - [Oct-27 18:47 POSTS] PageStore: getPagesWithLocalChanges
90 - [Oct-27 18:47 NOTIFS] notifications update job service > created
91 - [Oct-27 18:47 UTILS] Remote config updated: false
92 - [Oct-27 18:47 API] Dispatching action: AccountAction-FETCHED_SETTINGS
93 - [Oct-27 18:47 NOTIFS] notifications update service > completed
94 - [Oct-27 18:47 NOTIFS] notifications update job service > all tasks completed
95 - [Oct-27 18:47 NOTIFS] notifications update job service > destroyed
96 - [Oct-27 18:47 UTILS] trackLastActivity, activityId: Help Screen
97 - [Oct-27 18:47 UTILS] trackLastActivity, activityId: Help Screen
98 - [Oct-27 18:48 UTILS] trackLastActivity, activityId: Help Screen
99 - [Oct-27 18:48 UTILS] trackLastActivity, activityId: Help Screen 

[planarvoid]

thanks for the log @reginabally but there is nothing stats related in there :/. Are we sure the log is after the user tried opening/refreshing the stats?

[planarvoid]

@bummytime I haven't seen any logs yet that include what was added in June (look for fetchVisits string)

[reginabally]

Sorry, @planarvoid. I've sent the steps again to the user and requested for the new log.

[azollafox]

Here are the new logs:

01 - [Oct-28 09:40 STATS] SearchTermsStore: fetchSearchTerms
02 - [Oct-28 09:40 STATS] VideoPlaysStore: fetchVideoPlays
03 - [Oct-28 09:40 STATS] CountryViewsStore: getCountryViews
04 - [Oct-28 09:40 STATS] CountryViewsStore: getCountryViews
05 - [Oct-28 09:40 STATS] CountryViewsStore: fetchCountryViews
06 - [Oct-28 09:40 STATS] SearchTermsStore: fetchSearchTerms
07 - [Oct-28 09:40 STATS] SearchTermsStore: getSearchTerms
08 - [Oct-28 09:40 STATS] ClicksStore: getClicks
09 - [Oct-28 09:40 STATS] CountryViewsStore: getCountryViews
10 - [Oct-28 09:40 STATS] CountryViewsStore: getCountryViews
11 - [Oct-28 09:40 STATS] AuthorsStore: getAuthors
12 - [Oct-28 09:40 STATS] VideoPlaysStore: fetchVideoPlays
13 - [Oct-28 09:40 STATS] AuthorsStore: fetchAuthors
14 - [Oct-28 09:40 STATS] VideoPlaysStore: getVideoPlays
15 - [Oct-28 09:40 STATS] SearchTermsStore: fetchSearchTerms
16 - [Oct-28 09:40 STATS] FileDownloadsStore: fetchFileDownloads
17 - [Oct-28 09:40 STATS] SearchTermsStore: getSearchTerms
18 - [Oct-28 09:40 STATS] FileDownloadsStore: getFileDownloads
19 - [Oct-28 09:40 STATS] VideoPlaysStore: fetchVideoPlays
20 - [Oct-28 09:40 STATS] VideoPlaysStore: getVideoPlays
21 - [Oct-28 09:40 STATS] FileDownloadsStore: fetchFileDownloads
22 - [Oct-28 09:40 STATS] FileDownloadsStore: getFileDownloads
23 - [Oct-28 09:40 STATS] PostAndPageViewsStore: getPostAndPageViews
24 - [Oct-28 09:40 STATS] ClicksStore: getClicks
25 - [Oct-28 09:40 STATS] ReferrersStore: getReferrers
26 - [Oct-28 09:40 STATS] fetchVisits for week: Data fetched correctly
27 - [Oct-28 09:40 STATS] AuthorsStore: getAuthors
28 - [Oct-28 09:40 STATS] CountryViewsStore: getCountryViews
29 - [Oct-28 09:40 STATS] fetchVisits for week: Valid response returned for period: 2020-10-28
30 - [Oct-28 09:40 STATS] fetchVisits for week: Last data item for: 2020W10W26
31 - [Oct-28 09:40 STATS] VisitsAndViewsStore: getVisits
32 - [Oct-28 09:40 STATS] AuthorsStore: getAuthors
33 - [Oct-28 09:40 STATS] StatsStore: getTimeStatsTypes
34 - [Oct-28 09:40 STATS] VisitsAndViewsStore: getVisits
35 - [Oct-28 09:40 STATS] CountryViewsStore: fetchCountryViews
36 - [Oct-28 09:40 STATS] VisitsAndViewsStore: fetchVisits
37 - [Oct-28 09:40 STATS] fetchVisits for month: Site timezone: 1
38 - [Oct-28 09:40 STATS] fetchVisits for month: Current date: Wed Oct 28 06:56:07 GMT+01:00 2020
39 - [Oct-28 09:40 STATS] fetchVisits for month: Fetching for date with applied timezone: 2020-10-28
40 - [Oct-28 09:40 STATS] CountryViewsStore: getCountryViews
41 - [Oct-28 09:40 STATS] CountryViewsStore: getCountryViews
42 - [Oct-28 09:40 STATS] SearchTermsStore: fetchSearchTerms
43 - [Oct-28 09:40 STATS] SearchTermsStore: getSearchTerms
44 - [Oct-28 09:40 STATS] VideoPlaysStore: fetchVideoPlays
45 - [Oct-28 09:40 STATS] VideoPlaysStore: getVideoPlays
46 - [Oct-28 09:40 STATS] FileDownloadsStore: fetchFileDownloads
47 - [Oct-28 09:40 STATS] FileDownloadsStore: getFileDownloads
48 - [Oct-28 09:40 STATS] fetchVisits for month: Data fetched correctly
49 - [Oct-28 09:40 STATS] fetchVisits for month: Valid response returned for period: 2020-10-28
50 - [Oct-28 09:40 STATS] fetchVisits for month: Last data item for: 2020-10-01
51 - [Oct-28 09:40 STATS] VisitsAndViewsStore: getVisits
52 - [Oct-28 09:40 STATS] StatsStore: getTimeStatsTypes
53 - [Oct-28 09:40 STATS] VisitsAndViewsStore: getVisits
54 - [Oct-28 09:40 STATS] VisitsAndViewsStore: fetchVisits
55 - [Oct-28 09:40 STATS] fetchVisits for year: Site timezone: 1
56 - [Oct-28 09:40 STATS] fetchVisits for year: Current date: Wed Oct 28 06:56:07 GMT+01:00 2020
57 - [Oct-28 09:40 STATS] fetchVisits for year: Fetching for date with applied timezone: 2020-10-28
58 - [Oct-28 09:40 STATS] fetchVisits for year: Data fetched correctly
59 - [Oct-28 09:40 STATS] fetchVisits for year: Valid response returned for period: 2020-10-28
60 - [Oct-28 09:40 STATS] fetchVisits for year: Last data item for: 2020-01-01
61 - [Oct-28 09:40 STATS] VisitsAndViewsStore: getVisits
62 - [Oct-28 09:40 STATS] StatsStore: getTimeStatsTypes
63 - [Oct-28 09:40 STATS] StatsStore: getTimeStatsTypes
64 - [Oct-28 09:40 STATS] ClicksStore: fetchClicks
65 - [Oct-28 09:40 STATS] FileDownloadsStore: fetchFileDownloads
66 - [Oct-28 09:40 STATS] SearchTermsStore: fetchSearchTerms
67 - [Oct-28 09:40 STATS] VisitsAndViewsStore: fetchVisits
68 - [Oct-28 09:40 STATS] PostAndPageViewsStore: fetchPostAndPageViews
69 - [Oct-28 09:40 STATS] CountryViewsStore: fetchCountryViews
70 - [Oct-28 09:40 STATS] ReferrersStore: fetchReferrers
71 - [Oct-28 09:40 STATS] VideoPlaysStore: fetchVideoPlays
72 - [Oct-28 09:40 STATS] AuthorsStore: fetchAuthors
73 - [Oct-28 09:40 STATS] fetchVisits for day: Site timezone: 1
74 - [Oct-28 09:40 STATS] fetchVisits for day: Current date: Wed Oct 28 06:56:07 GMT+01:00 2020
75 - [Oct-28 09:40 STATS] fetchVisits for day: Fetching for date with applied timezone: 2020-10-28
76 - [Oct-28 09:40 STATS] AuthorsStore: getAuthors
77 - [Oct-28 09:40 STATS] PostAndPageViewsStore: getPostAndPageViews
78 - [Oct-28 09:40 STATS] ReferrersStore: getReferrers
79 - [Oct-28 09:40 STATS] CountryViewsStore: getCountryViews
80 - [Oct-28 09:40 STATS] fetchVisits for day: Data fetched correctly
81 - [Oct-28 09:40 STATS] fetchVisits for day: Valid response returned for period: 2020-10-28
82 - [Oct-28 09:40 STATS] fetchVisits for day: Last data item for: 2020-10-28
83 - [Oct-28 09:40 STATS] VisitsAndViewsStore: getVisits
84 - [Oct-28 09:40 UTILS] trackLastActivity, activityId: My Site
85 - [Oct-28 09:40 API] Dispatching action: AccountAction-FETCH_ACCOUNT
86 - [Oct-28 09:40 API] WhatsNewStore: fetchWhatsNew
87 - [Oct-28 09:40 API] Dispatching action: AccountAction-FETCHED_ACCOUNT
88 - [Oct-28 09:40 UTILS] trackLastActivity, activityId: Site Picker
89 - [Oct-28 09:40 UTILS] trackLastActivity, activityId: My Site
90 - [Oct-28 09:40 API] Dispatching action: AccountAction-FETCH_ACCOUNT
91 - [Oct-28 09:40 API] WhatsNewStore: fetchWhatsNew
92 - [Oct-28 09:40 API] Dispatching action: AccountAction-FETCHED_ACCOUNT
93 - [Oct-28 09:40 API] Dispatching action: WhatsNewAction-FETCH_CACHED_ANNOUNCEMENT
94 - [Oct-28 09:40 API] WhatsNewStore: fetchWhatsNew
95 - [Oct-28 09:40 API] Dispatching action: AccountAction-FETCH_SETTINGS
96 - [Oct-28 09:40 API] Dispatching action: WhatsNewAction-FETCH_REMOTE_ANNOUNCEMENT
97 - [Oct-28 09:40 API] WhatsNewStore: fetchWhatsNew
98 - [Oct-28 09:40 API] Dispatching action: AccountAction-FETCHED_SETTINGS
99 - [Oct-28 09:40 UTILS] trackLastActivity, activityId: Help Screen

[planarvoid]

thanks @sarahfg , and just to be sure - this user with these logs is seeing the wrong stats? The requests seem absolutely correct. We're fetching the data for the correct dates and the Last data item seems to be today. Or is this for the user who was able to recover?

[rezzap]

Another report of this in 3525901-zen

User was able to get this working by clearing app data and cache, but it returned again on the same day they were on when it originally came up. I'm asking them if a pull down to refresh helps now.

Pixel 4a using WP app 16.1 last we checked.

They report this did not happen on their other device: (pixel 1/android 10).

Update: The pull to refresh did not change the date neither did moving away from the stats screen and coming back to it. Only a reboot did. There is some helpful information about how the user uses the stats:

if the date is wrong i do not remember a refresh ever 'fixing' things. certainly it didn't this morning. (today is dec 5. the stats page said either dec 4 or dec 3 -- i don't remember. a 'refresh' didn't change anything. a reboot did

one morning i tried at 5:38 AM and the date was the previous day. 'most' days it's mid-to-late morning.

yesterday-to-today i did keep it on that pager when i shut the app down. sometimes i don't. as far as i'm aware, there is no correlation between that and correct date rollover.

They also shared screenshots of the first graph showing the day from yesterday and then when clicking on the post that got the view, the correct date is reflected in the stats.

[planarvoid]

I'm adding some tracking for the cases when the stats shown to the user are out-of-date in #13556 . I want to find out how common that is and what sites are usually showing the out-of-date stats.

[reginabally]

Another report in 3573427-zen. Samsung SM-A405FN on WPAndroid 16.2.

The user noticed the issue happens intermittently. In the log, I see the following log entries. The user mentioned they were seeing the date December 13th all-day whereas their current date was December 14th. They confirmed the phone and site's timezones match.

52 - [Dec-14 14:08 STATS] fetchVisits for month: Current date: Sun Dec 13 21:52:42 GMT+01:00 2020
53 - [Dec-14 14:08 STATS] fetchVisits for month: Fetching for date with applied timezone: 2020-12-13

For now, I asked them to perform a fresh installation of the app let us know if they experience the same issue again.

[planarvoid]

thanks @reginabally ! this was actually super helpful and we managed to find a bug in the code (thanks @malinajirka 🙇 ). We've merged a fix so let's observe this issue and see if it comes back.