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

RESOLVED FIXED

Status

Cloud Services
Firefox: Common
RESOLVED FIXED
2 years ago
8 months ago

People

(Reporter: dholbert, Assigned: mgoodwin)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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

*************************
(Reporter)

Comment 1

2 years ago
(ni=mgoodwin since he added this file)
Flags: needinfo?(mgoodwin)
(Assignee)

Comment 2

2 years ago
Ok; will take a look
Assignee: nobody → mgoodwin
Flags: needinfo?(mgoodwin)

Updated

2 years ago
Duplicate of this bug: 1259623
Saw this too this morning.
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"
}
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
See Also: → bug 1257533
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
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.