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

RESOLVED FIXED in Firefox 28

Status

defect
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: nkot, Assigned: albert)

Tracking

({regression})

unspecified
1.3 Sprint 6 - 12/6
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.3+, firefox28 fixed)

Details

(Whiteboard: [xfail])

Attachments

(2 attachments)

Posted file 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
blocking-b2g: --- → 1.3?
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.
QA Contact: 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.
Probably related to the same problems talked about in https://bugzilla.mozilla.org/show_bug.cgi?id=942060#c10.
Duplicate of this bug: 944243
Let me check if this is a back-end or front-end problem.
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.
Keywords: regression
Assignee: nobody → acperez
triage: 1.3+ broken feature
blocking-b2g: 1.3? → 1.3+
(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.
Keywords: regression
Ok. Understood. Sorry for the misinterpretation.
Whiteboard: [xfail]
Posted patch PatchSplinter Review
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.
Attachment #8340240 - Flags: review?(gene.lian)
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
Attachment #8340240 - Flags: review?(gene.lian) → review+
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.
Flags: needinfo?(jshih)
Nice catch, Albert! It has no affect for per-app part and fixes the bug clearly :)
Flags: needinfo?(jshih)
Keywords: regression
Component: Gaia::Cost Control → General
https://hg.mozilla.org/mozilla-central/rev/8fe38055e41a
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.3 Sprint 6 - 12/6
You need to log in before you can comment on or make changes to this bug.