1475528 - Error checking filter for "Pref Flip Study: Trusted Recursive Resolver (count OUT), Nightly [Bug 1446404]"

Status: RESOLVED FIXED

(Shield :: Shield Study, defect)

Description

[Rob Wu [:robwu]]

Firefox stable (61.0.1) and Firefox Nightly (63): When I create a new profile directory and launch Firefox, the following error appears in the global console:

app.normandy.recipe-runner	ERROR	Error checking filter for "Pref Flip Study: Trusted Recursive Resolver (count OUT), Nightly [Bug 1446404]". Filter: [(
  normandy.channel == 'nightly'
  && normandy.version >= '62'
  && 'network.trr.experimentalRollout'|preferenceValue in [-1, -3]
)]. Error: "Error: Token - (binaryOp) unexpected in expression: (   normandy.channel == 'nightly'   && normandy.version >= '62'   && 'network.trr.experimentalRollout'|preferenceValue in [-1, -"

Based on the above error message, I created the following minimal reproduction steps:

Cu.import("resource://gre/modules/components-utils/FilterExpressions.jsm",{}).FilterExpressions.eval(`[(
  normandy.channel == 'nightly'
  && normandy.version >= '62'
  && 'network.trr.experimentalRollout'|preferenceValue in [-1, -3]
)]`).then(console.log)

The above snippet is for Nightly. For stable, use the following JSM import instead:
Cu.import("resource://normandy/lib/FilterExpressions.jsm",{}).FilterExpressions.eval(`[(

I have no idea where this expression comes from, but the error can be fixed by replacing
  && 'network.trr.experimentalRollout'|preferenceValue in [-1, -3]
with
  && 'network.trr.experimentalRollout'|preferenceValue in [(-1), (-3)]
(or: [-1, (-3)] - any negative value after the first one needs to be between parentheses)

(it seems that the mozjexl parser does not recognize unary minus, and treats the minus as a binary operator)

Comment 1

[Matt Grimes [:Matt_G]]

Thanks for the heads up. I'll have one of my people take a look.

Comment 2

[Josh Gaunt [:jgaunt]]

Filter expression has been revised...

Comment 3

[Michael Cooper [:mythmon]]

Rob, thanks for the detailed bug report. The filter expression comes from data on the Normandy server, and Matt's team can fix it there. The root cause here seems to be that the server validator didn't see this as a syntax error. We'll need to fix that.

I've moved this over to the Shield component, since it is a problem with a particular recipe. I'll file other bugs for a fix to the underlying problem. In the short term, probably disallowing the problematic syntax on the server, and later hopefully fixing the parser in the browser.

If you're curious, here is the history of the recipe in question in the API: https://normandy.cdn.mozilla.net/api/v1/recipe/512/history/

I see that the recipe has been edited on the server to include the fix proposed in comment 0, and that change has been approved. I'm going to mark this bug as fixed.