1368977 - [Shield] Executing Heartbeat type recipe fail - TypeError: can't access dead object

Status: VERIFIED FIXED

(Shield :: General, defect)

Description

[Adrian Florinescu [:aflorinescu]]

[Enviroment:]
Nightly 55.0a1 20170530100155 


[Preconditions:]
1. Obtain a copy of Firefox with the SHIELD recipe client system add-on installed. You can check about:support to ensure that you have it.
2. Set the extensions.shield-recipe-client.dev_mode preference to true to run recipes immediately on startup.
3. Set the extensions.shield-recipe-client.logging.level preference to 0 to enable more logging.
4. Set the security.content.signature.root_hash preference to DB:74:CE:58:E4:F9:D0:9E:E0:42:36:BE:6C:C5:C4:F6:6A:E7:74:7D:C0:21:42:7A:03:BC:2F:57:0C:8B:9B:90.
5. Set the preference value for extensions.shield-recipe-client.api_url set to https://normandy.stage.mozaws.net/api/v1

[Steps:]
1. Create and enable a heartbeat type recipe.
2. Open FF and set preconditions to a FF client.
3. Restart the FF client.

[Actual Result:]
Error: Tried to use sandbox after it was nuked  SandboxManager.jsm:27:11
TypeError: can't access dead object[Learn More]

-full browser console from runs on two profiles: See https://pastebin.mozilla.org/9023141 

[Expected Result:]
Heartbeat to be displayed.

Comment 1

[Osmose [:osmose, :mkelly]]

I can replicate this using both the latest synced version to mozilla-central, AND the latest master from the Github repo, but only in Nightly. I can't replicate on Firefox Developer Edition, or on 53 using the unbranded build to install the latest add-on.

I think this might be a Nightly-specific bug and will look into it, but if we can't replicate it on Beta or Release, I think this shouldn't block us uplifting preference experiments to Beta.

Adrian: How does that sound to you?

Comment 2

[Osmose [:osmose, :mkelly]]

I've tracked this down to an issue with how we compile and minify our JavaScript, which is mangling the promise being returned by actions. The fix is a server-side only fix, so resolving this is not dependent on landing code in Firefox.

Comment 3

[Adrian Florinescu [:aflorinescu]]

I don't know how we are time wise and how much would it take for the above issue to be fixed and landed?
I would rather have the safe approach with this fix up so we can test the recipe types integration before moving forward.

Comment 4

[[github robot]]

Commit pushed to master at https://github.com/mozilla/normandy

https://github.com/mozilla/normandy/commit/4c843784568c6cf09d574ed9ea7bc215cf8c6053
Fix bug 1368977: Remove es2015 and stage-0 preset from Babel. (#791)

* Fix bug 1368977: Remove es2015 and stage-0 preset from Babel.

The minimum Firefox version that we target for both the system add-on
and the website is Firefox 52, which includes support for most es2015
features, including native async/await syntax. This means we can safely
switch to using those features without transpiling them via Babel.

This removes both the es2015 and stage-0 presets from Babel, and
includes a few individual plugins that we still need support for.
This also adds a new Webpack plugin to enable it to parse async/await
syntax while resolving modules.

UglifyJS can't parse async/await syntax, even on the harmony branch, so
this switches to using Babili for minification. We use the webpack
plugin instead of including it in the Babel config so that code inside
node_modules, which is ignored by babel-loader, also gets minified.

* Switch to app user in linting Dockerfile before running npm install.

This is a workaround for a permissions-related npm crash within Docker
on CircleCI. See also:

- https://github.com/npm/npm/issues/16892
- https://github.com/npm/npm/issues/16766
- Similar yarn issue with the workaround:
  https://github.com/yarnpkg/yarn/issues/918

Comment 5

[Osmose [:osmose, :mkelly]]

The fix for this is now on staging. We will deploy to prod after some work on our CDN to account for the changes in filesize for our static resources.

Adrian: Given that uplift is next week, if we can verify this as fixed on staging, can we get approval to merge to Beta?

Comment 6

[Adrian Florinescu [:aflorinescu]]

(In reply to Michael Kelly [:mkelly,:Osmose] from comment #5)
> Adrian: Given that uplift is next week, if we can verify this as fixed on
> staging, can we get approval to merge to Beta?
If we're planning to ride the merge, I think we can make, after this bug, I've added additional heartbeat tests and I also plan to run again some of the experiment cases. As a rough estimate, assuming nothing new is uncovered should have us ready for a sign off tomorrow.

Comment 7

[Osmose [:osmose, :mkelly]]

Righto. 

Also, this got deployed to production yesterday. Should be everywhere now.

Comment 8

[Adrian Florinescu [:aflorinescu]]

Verifying as fixed on 55.0a1 20170607030206