1259145 - "TypeError: versionInfo.data is undefined" in kinto-updater.js

Status: RESOLVED FIXED

(Cloud Services :: Firefox: Common, defect)

Description

[Daniel Holbert [:dholbert]]

Just saw this go by in my terminal-spew, in a debug build with a fresh profile. I don't know if there are concrete STR -- I basically just ran "./mach run" and let it sit for a while.

Looks like kinto-updater.js (the file where we're using an undefined value) was just recently checked in, in bug 1224531 -- marking this as blocking that bug.

*************************
A coding exception was thrown and uncaught in a Task.

Full message: TypeError: versionInfo.data is undefined
Full stack: this.checkVersions/<@resource://services-common/kinto-updater.js:48:14
TaskImpl_run@resource://gre/modules/Task.jsm:319:40
promise callback*TaskImpl_handleResultValue@resource://gre/modules/Task.jsm:395:7
TaskImpl_run@resource://gre/modules/Task.jsm:327:13
promise callback*TaskImpl_handleResultValue@resource://gre/modules/Task.jsm:395:7
TaskImpl_run@resource://gre/modules/Task.jsm:327:13
TaskImpl@resource://gre/modules/Task.jsm:280:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:254:14
Task_spawn@resource://gre/modules/Task.jsm:168:12
this.checkVersions@resource://services-common/kinto-updater.js:24:10
Blocklist.prototype.notify@file:///scratch/work/builds/mozilla-inbound/obj/dist/bin/components/nsBlocklistService.js:636:7
TM_notify/<@file:///scratch/work/builds/mozilla-inbound/obj/dist/bin/components/nsUpdateTimerManager.js:201:11
TM_notify@file:///scratch/work/builds/mozilla-inbound/obj/dist/bin/components/nsUpdateTimerManager.js:249:7

*************************

Comment 1

[Daniel Holbert [:dholbert]]

(ni=mgoodwin since he added this file)

Comment 2

[Mark Goodwin [:mgoodwin]]

Ok; will take a look

Comment 4

[Benjamin Bouvier [:bbouvier] (inactive)]

Saw this too this morning.

Comment 5

[Jarda Snajdr [:jsnajdr]]

This is how the versionInfo object looks like when this error happens:

{
  "errno":201,
  "message":"Service temporary unavailable due to overloading or maintenance, please retry later.",
  "code":503,
  "error":"Service Unavailable"
}

Comment 6

[Mathieu Leplatre [:leplatrem]]

A `Retry-After` response header should also be returned by the server [0]. It indicates the number of seconds to wait before retrying a new request.


[0] http://kinto.readthedocs.org/en/latest/api/1.x/cliquet/errors.html

Comment 7

[Mathieu Leplatre [:leplatrem]]

Following-up from https://bugzilla.mozilla.org/show_bug.cgi?id=1257533#c16

> Notice that we have a generic pattern for all calls, where we should check the status code we get back and parse the error. 
> I don't know where this code should be (kinto.js vs Firefox layer) but it should be used for any call to kinto.
> 

The current code for polling blocklist changes was implemented using the «vanilla» fetch() API.

Since the *changes endpoint* is nothing more than a usual collection of records, we could update the code to rely on kinto.js `sync()` instead.

This would have the advantage of conveying every interaction with the Kinto server through only one library.

Alternatively, it is rather trivial to just add a safety check in the current code.

In both approaches, we should decide what to do when an error occurs (Kinto.js raises nicely but takes no decision):

* Retry after some time (as obtained via the `Retry-After` value obtained from errors response headers)
* Wait for the next call to `notify()` (i.e. 24H)

Note: Kinto.js embeds kinto-client [0] which is responsible of very HTTP interaction with the server (error protocol etc.)

[0] https://github.com/Kinto/kinto-client