1919140 - JEXL support

Status: RESOLVED FIXED

(Application Services :: Remote Settings, enhancement, P1)

Description

[Ben Dean-Kawamura [:bdk]]

See https://remote-settings.readthedocs.io/en/latest/target-filters.html

client.get() returns all records of the collection that match current filters. If a record doesn’t have the filter_expression field, then it is considered as matching.

The filter_expression is executed against a context, that is made available in the env variable, and we filter the records where the expression returns a truthy value.

use jexl_eval::Evaluator;
use serde_json::json as value;

let context = value!({"env": {"channel": "beta"}});
let evaluator = Evaluator::new();
assert_eq!(
  evaluator.eval_in_context("env.channel=='release'", context).unwrap(),
  value!(true)
);

Required fields for the application context:

• version
• Channel
• <TBD>

Comment 1

[Bastian Gruber]

This PR adds the option to set a RemoteSettingsContext when creating a new client. Each get_records() will then check if a context is set, and filter based on that context.

It also adds one transfomer (version_compare).

https://github.com/mozilla/application-services/pull/6449

Comment 2

[Mathieu Leplatre [:leplatrem]]

The PR just landed, congrats everyone!

Should we keep this ticket open until most transforms are implemented? Or should we mark it as fixed and open follow-ups?

Since our primary use-case is going to be the Search component, and since the whole list of desktop transforms is long, Mark you could maybe help us narrow down the scope that you would need?

From what I can see in PROD data:

$ curl -s "https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/search-config-icons/records?_fields=filter_expression" | jq '.data[].filter_expression' | sort
-u
"env.appinfo.ID == \"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}\" && env.version|versionCompare(\"128.0a1\") <= 0"
"env.appinfo.ID == \"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}\" && env.version|versionCompare(\"128.0a1\") > 0"
"env.appinfo.ID == \"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}\""

It looks like appinfo.ID and env.version|versionCompare would be enough.
Do you confirm?

Comment 3

[Mark Banner (:standard8)]

(In reply to Mathieu Leplatre [:leplatrem] from comment #2)

Should we keep this ticket open until most transforms are implemented? Or should we mark it as fixed and open follow-ups?

I'm fine either way, follow-ups work as well & show progress.

From what I can see in PROD data:

$ curl -s "https://firefox.settings.services.mozilla.com/v1/buckets/main/collections/search-config-icons/records?_fields=filter_expression" | jq '.data[].filter_expression' | sort
-u
"env.appinfo.ID == \"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}\" && env.version|versionCompare(\"128.0a1\") <= 0"
"env.appinfo.ID == \"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}\" && env.version|versionCompare(\"128.0a1\") > 0"
"env.appinfo.ID == \"{ec8030f7-c20a-464f-9b0e-13a3a9e97384}\""

It looks like appinfo.ID and env.version|versionCompare would be enough.
Do you confirm?

It may be useful to have appinfo.channel as well (or is that env.channel?), but it looks like that's already been implemented? I was thinking about using it the other day for search-telemetry-v2 cases.

As far as I know, those would be enough for the search cases.

I think preferenceValue would be the only other one that I would guess might be a higher priority after the search cases - its already used in a filter_expression on the cert-revocations collection, and it feels like it'd be potentially useful for experiments.