One flag service, every request’s user, then prerequisites
A feature-flag service stores each flag’s targeting rule as an expression tree, as the lesson’s help desk stores a saved view, and interprets it for every request against that request’s user: their plan, whether they joined the beta, and the country the geo lookup found, which can be unknown. Each level starts from the previous level’s finished code, so you can begin at any of them.
The flag service decides thousands of flags a second, and a profile showed prerequisite lookups high on the list. Pull request #318 remembers each prerequisite’s answer the first time it is worked out, in one table the whole service shares, and makes CountryIn answer false when the country is unknown, because the missing-country errors were filling the logs. One reviewer approved it; it is waiting for yours.
In staging, the new navigation turned on for everyone as soon as the first beta user loaded a page, and an edited prerequisite kept its old answer until the service restarted. The flag for tools that may not be offered in the US turned on for every user the geo lookup could not place.
Reproduce With new-nav saved as Beta, Requires('new-nav') decides on for Ada (beta) and then on for Bo, who is not in the beta. NOT CountryIn(['US']) decides on for Cy, whose country is unknown.
Acceptance criteria Every evaluation answers for its own user: a prerequisite decided for one user never decides it for another. An edited flag answers with its new rule on the next request. A CountryIn reached for a user with no country is still the error missing-country, under NOT too, and inside a prerequisite. INTERPRETER-101’s and 102’s rules still hold: own codes, prerequisites in the same context, unknown-flag, left sides first. Notes Each case gives the flags as saved, then decides one rule for each user in turn; a case with two rounds saves the flags again between them (an edit) and prints both rounds’ lines. Keep the names and constructors of the expression types and the signature of decide.