1078120 - [Telemetry] The timestamp for AMU is pulled in before the system clock gets synchronized

Status: RESOLVED DUPLICATE of bug 1072075

(Firefox OS Graveyard :: Gaia::System, defect)

Description

[Shing Lyu [:shinglyu]]

[Blocking Requested - why for this release]:

This

# Summary
  This is a follow-up bug for Bug 1071443 Comment 7: "The timestamps for startTime / stopTime seem to be pulled in some cases before the system clock gets synchronized, and AUM doesn't do anything to update it's measurements when that happens"

# Steps:
  (Steps needed from Marshall)

# Expected:
  The AMU should update it's measurement when system clock get synchronized.

# Actual:
  The AMU doesn't do anything.

# Reproduction Frequency:
  (Need info from Marshall)

Comment 1

[Shing Lyu [:shinglyu]]

Hi Marshall,

Can you provide more detail about the steps to reproduce this issue you mentioned? Thank you.

Comment 2

[Marshall Culpepper [:marshall_law]]

It seems to be a race condition, so it isn't easily reproducible, but usually I see it happen like this:

* Set AUM.DEBUG to true, and the REPORT_INTERVAL/RETRY_INTERVAL to low numbers, I use 30000 (30 sec)
* Add this debug line in AUM.prototype.handleEvent, after the big switch statement:

debug('metrics.startTime =', new Date(this.metrics.startTime()), 'lastFailedTransmission =', new Date(this.lastFailedTransmission), 'now =', new Date(now));

* Reset the device (I just use reset-gaia)
* In FTU, Enable / Connect to a WiFi network
* Watch and copy the log for the statements above to see if |metrics.startTime| is 'after' |now|
* If it is, then you've reproduced the issue.

You'll notice that when this happens, the startTime in the future is persisted, and AUM never actually transmits it's data until the system clock 'catches up'

I think this might also be fixed by David's upcoming Performance.now() fix

Comment 3

[David Flanagan [:djf]]

This will be fixed by the patch in bug 1072075

Comment 4

[Gregor Wagner [:gwagner]]

Removing nom since its a dupe.