944008 - [B2G][Usage] Usage reset doesn't work properly

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Natalya Kot [:nkot]]

Attachment: logcat

Description:
Usage Reset doesn't seem to work properly. It requires to tap Reset button a few times to clear off data usage. After tapping Reset button for the first time the usage number actually increases, tapping it again will eventually set usage to 0.00.

Repro Steps:
1) Updated Buri to BuildID: 20131127040203
2) Set up the Usage app to track data
3) Browse YouTube or any website and then close browser app 
4) Open Usage app and note the usage number (5.28MB)
5) Open Usage settings and tap Reset button

Actual:
 Usage number jumps up (36.34MB), the user has to tap Reset button a few times to set data usage to 0.00

Expected:
 Usage number drops off to 0.00 (or at least gets down in case if there is still some browser activity in the background)
 

Environmental Variables:
Device: Buri v1.3 M-C Mozilla RIL
BuildID: 20131127040203
Gaia: d4b9a3d271f0451b4d903a03c2b931b8cc092041
Gecko: 6ecf0c4dfcbe
Version: 28.0a1
Firmware Version: v1.2_20131115


Repro frequency: 80%, 3/3 devices
See attached logcat

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

looks like we're getting intermittenant working and not working: bug 938946

Looks like a real API was needed : bug 937247 at the same time bug 937240 landed 11/22.  Should be in the 11/23 build.

Please check the 11/23 build and the 11/22 build to see this might be the regression range.

Comment 2

[gbennett]

.:First Broken Build:.
Environmental Variables:
Device: Buri 1.3 mozRIL
BuildID: 20131121040202
Gaia: 71063dd91bc8cbb15ba335236ed67a1c5058bd58
Gecko: cf378dddfac8
Version: 28.0a1
Firmware Version: 20131115

.:Last Working Build:.
Environmental Variables:
Device: Buri 1.3 mozRIL
BuildID: 20131120040202
Gaia: c26480b22ce28c812c347290dd4bad090d83db6f
Gecko: 4f993fa378eb
Version: 28.0a1
Firmware Version: 20131115

I also checked 11/23 and 11/22, both builds repro this issue. Super close guess Naoki.

Comment 3

[Jason Smith [:jsmith]]

Probably related to the same problems talked about in https://bugzilla.mozilla.org/show_bug.cgi?id=942060#c10.

Comment 5

[Salvador de la Puente González [:salva]]

Let me check if this is a back-end or front-end problem.

Comment 6

[Salvador de la Puente González [:salva]]

It seems to be a back-end bug. This is the first time we use the real `reset` of the API. The lack of multi-sim support in the former API prevent us to loose the historical data so, instead, we were only saving fixing values.

I'm removing the regression keyword because it is not a regression. Moving to new Network Statistics API involves to use the real reset functionality which was never used before. If this is not affordable, we have the know-how to provide a Gaia workaround but the solution will be suboptimal.

The provided STR is enough. This is happening on master, latest Gecko.

Comment 7

[Joe Cheng [:jcheng] (please needinfo)]

triage: 1.3+ broken feature

Comment 8

[Jason Smith [:jsmith]]

(In reply to Salvador de la Puente González [:salva] from comment #6)
> It seems to be a back-end bug. This is the first time we use the real
> `reset` of the API. The lack of multi-sim support in the former API prevent
> us to loose the historical data so, instead, we were only saving fixing
> values.
> 
> I'm removing the regression keyword because it is not a regression. Moving
> to new Network Statistics API involves to use the real reset functionality
> which was never used before. If this is not affordable, we have the know-how
> to provide a Gaia workaround but the solution will be suboptimal.

Switching to a new API backend in which old functionality no longer works still counts as a regression. It just means the new API backend isn't meeting quality requirements of the old API setup. There's a window to prove that. Re-adding keyword.

Comment 9

[Salvador de la Puente González [:salva]]

Ok. Understood. Sorry for the misinterpretation.

Comment 10

[Albert [:albert]]

Attachment: Patch

There is a problem after cleaning the database when setting the first value for a given interface in order to keep the track of the netd rx/tx values. Currently it is considered the last value before cleaning as the new reference value, but this is wrong because now we have perapp stats stored with the global ones and sometimes the value taken for reference is one with appId != 0 and it makes the wrong behavior.

The patch checks the appId to ensure we are taking the correct reference value.

Comment 11

[Gene Lian (I already quit Mozilla)]

Comment on attachment 8340240 [details] [diff] [review]
Patch

Review of attachment 8340240 [details] [diff] [review]:
-----------------------------------------------------------------

Nice! Thank you for catching this. Please go ahead to land. :)

r=gene

Comment 12

[Gene Lian (I already quit Mozilla)]

Hi John, please take a look at this bug and think about if we'd have any other side-effect like this after introducing the per-app metering.

Comment 13

[John Shih]

Nice catch, Albert! It has no affect for per-app part and fixes the bug clearly :)

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/8fe38055e41a

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8fe38055e41a