1812040 - console errors emitted in xpcshell-tests/mochitests/marionette/webdriver using remote settings dummy url (Unexpected content-type \"text/plain;charset=US-ASCII\)

Status: RESOLVED FIXED

(Firefox :: Remote Settings Client, defect)

Description

[Mark Banner (:standard8)]

If I run a test that's set up using one of the dummy urls that were added in bug 1807667, then I will commonly see in the output one or more of these:

console.error: (new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.jsm", 407))

Unexpected warnings can be especially difficult for developers to understand.

Would it be possible to either disable this error in those cases or find a url which would avoid it?

Comment 1

[Mark Banner (:standard8)]

Note, I've just added an allow list entry for this message in bug 1809637 which is improving our console message detection.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1807667

:yarik, since you are the author of the regressor, bug 1807667, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 3

[Yarik Kurmyza [:yarik] (he/him) (UTC+1)]

hey Mark, can you please let me know how to trigger that specific console errors? Which tests do you run so I could reproduce it locally?
This problem was mentioned in that patch

I wonder if we could also disable remote settings in those tests

Comment 4

[Mark Banner (:standard8)]

(In reply to Yarik Kurmyza [:yarik] (he/him) (UTC+1) from comment #3)

hey Mark, can you please let me know how to trigger that specific console errors? Which tests do you run so I could reproduce it locally?

Sorry, I meant to put that in and forgot. Here's one example:

./mach mochitest toolkit/modules/tests/browser/browser_Troubleshoot.js

I wonder if we could also disable remote settings in those tests

Only on the network side. For example, I've seen this in the search tests, and we use remote settings there as that's where we load the search configuration from.

Comment 5

[Yarik Kurmyza [:yarik] (he/him) (UTC+1)]

So I've checked again and discovered that if you don't provide any services.settings.server value at all, Remote Settings client would not even try to fetch the changes, and no errors would be shown.
I have obviously no experience with those tests and don't know what problems that might cause, or if it would be possible to only specify server url for Remote Setting tests only.

Comment 6

[Yarik Kurmyza [:yarik] (he/him) (UTC+1)]

So, I played a bit with variations of data urls, and the only thing that changes is the error message. It goes much deeper into the logic of remote settings client:

user_pref("services.settings.server", "http://localhost:7777/#remote-settings-dummy/v1");
(new TypeError("NetworkError: Network request failed", "resource://services-settings/Utils.jsm", 237))

user_pref("services.settings.server", "data:application/json,null#remote-settings-dummy/v1");
(new TypeError("can't access property \"hasOwnProperty\", payload is null", "resource://services-settings/Utils.jsm", 417))

user_pref("services.settings.server", "data:application/json,#remote-settings-dummy/v1");
(new Error("Server error data:application/json,#remote-settings-dummy/v1/buckets/monitor/collections/changes/changeset?collection=quicksuggest&bucket=main&_expected=0 200 OK: \"JSON.parse: unexpected end of data at line 1 column 1 of the JSON data\"", "resource://services-settings/Utils.jsm", 422))

user_pref("services.settings.server", "#");
(new SyntaxError("The URI is malformed.", (void 0), 133))

user_pref("services.settings.server", "data:,#");
user_pref("services.settings.server", "data:,#remote-settings-dummy/v1");
(new Error("Unexpected content-type \"text/plain;charset=US-ASCII\"", "resource://services-settings/Utils.jsm", 407))

// payload: {}
user_pref("services.settings.server", "data:application/json;base64,e30=");
(new TypeError("NetworkError: Network request failed", "resource://services-settings/Utils.jsm", 237))

// payload: {}
user_pref("services.settings.server", "data:application/json;base64,e30=#");
(new Error("Server error data:application/json;base64,e30=#/buckets/monitor/collections/changes/changeset?collection=quicksuggest&bucket=main&_expected=0 200 OK: {}", "resource://services-settings/Utils.jsm", 422))

// payload: {"collection": []}
user_pref("services.settings.server", "data:application/json;base64,eyJjaGFuZ2VzIjpbXX0=#");
(new UnknownCollectionError("Unknown Collection \"main/quicksuggest\"", "resource://services-settings/RemoteSettingsClient.jsm", 197))

// payload: {"collection": []}
user_pref("services.settings.server", "data:application/json;base64,eyJjaGFuZ2VzIjpbXX0=");
(new TypeError("NetworkError: Network request failed", "resource://services-settings/Utils.jsm", 237))

// payload: {"changes":["1"]}
user_pref("services.settings.server", "data:application/json;base64,eyJjaGFuZ2VzIjpbIjEiXX0=#remote-settings-dummy/v1");
new DataError("IndexedDB: main/quicksuggest importChanges() IndexedDB: collections, timestamps, records importChanges() in main/quicksuggest Data provided to an operation does not meet requirements.", "resource://services-settings/IDBHelpers.jsm", 18))

// payload: // {"metadata":{},"timestamp":1674746085080,"changes":[{"id":"3ddbe540","last_modified":1674166327238,"bucket":"main","collection":"quicksuggest","host":"moz.org"},{"id":"3ddbe540","last_modified":1674166327238,"bucket":"main","collection":"query-stripping","host":"moz.org"}]}
user_pref("services.settings.server", "data:application/json;base64,eyJtZXRhZGF0YSI6e30sInRpbWVzdGFtcCI6MTY3NDc0NjA4NTA4MCwiY2hhbmdlcyI6W3siaWQiOiIzZGRiZTU0MCIsImxhc3RfbW9kaWZpZWQiOjE2NzQxNjYzMjcyMzgsImJ1Y2tldCI6Im1haW4iLCJjb2xsZWN0aW9uIjoicXVpY2tzdWdnZXN0IiwiaG9zdCI6Im1vei5vcmcifSx7ImlkIjoiM2RkYmU1NDAiLCJsYXN0X21vZGlmaWVkIjoxNjc0MTY2MzI3MjM4LCJidWNrZXQiOiJtYWluIiwiY29sbGVjdGlvbiI6InF1ZXJ5LXN0cmlwcGluZyIsImhvc3QiOiJtb3oub3JnIn1dfQ==#remote-settings-dummy/v1");
console.error: services.settings:
  main / query - stripping Signature failed  MissingSignatureError: Missing signature(main / query - stripping)
console.error: services.settings:
  main / query - stripping local data was corrupted
console.warn: services.settings: main / query - stripping Signature verified failed.Retry from scratch
console.error: services.settings:
  main / query - stripping Signature failed again MissingSignatureError: Missing signature(main / query - stripping)
console.error: (new MissingSignatureError("Missing signature (main/query-stripping)", "resource://services-settings/RemoteSettingsClient.jsm", 174))

So I don't currently see how we could solve this issue with data urls only.
Possibility 1: patch remote settings client to be aware of test scenarios and gracefully exit
Possibility 2: ignore such errors
Possibility 3: setup dev server to respond to those calls

The beauty of those data urls is that it doesn't result in the network call, so test eventually finish faster.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:leplatrem, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 11

[Mark Banner (:standard8)]

Yarik, I just saw bug 1810074 comment 18, and wondered... If this logging is coming from here as the comment suggests, would it be safe to detect that the server URL is data:,#remote-settings-dummy/v1 (or whatever the current version is), and not throw an error but return silently?

We could maybe do a log.info which would provide more logging only if the remote settings level is appropriately set.

Comment 12

[Yarik Kurmyza [:yarik] (he/him) (UTC+1)]

Yeah, this is a good solution probably. Will make a code a bit less pretty, but would avoid logging those errors.

Another option is to avoid fetching entries in the first place if the URL is like that. Mat should probably know more about that part.

Comment 13

[Mark Banner (:standard8)]

Attachment: Bug 1812040 - Avoid remote settings errors emitted in tests when using the dummy url. r?leplatrem!

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This also affects the webdriver tests, which use this dummy URL now as well (see bug 1851376).

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d071ea331761
Avoid remote settings errors emitted in tests when using the dummy url. r=leplatrem

Comment 16

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/d071ea331761