[JamesPatrickGill]

Problem

• A flag with two or more evaluation contexts gets a different array from each of the two cache builders, so the shadow comparison between them reports an evaluation_contexts field mismatch.
• Python aggregates the names with ArrayAgg(..., distinct=True), which Postgres renders as array_agg(DISTINCT ...). That sorts them.
• Rust used a bare ARRAY_AGG with neither DISTINCT nor ORDER BY. Postgres guarantees no row order without one, so Rust returned join order, and could return a different order between runs.

Changes

• The Rust builder emits ARRAY_AGG(DISTINCT ctx.name), so both builders produce the same sorted array (rust/feature-flags/src/flags/feature_flag_list.rs).
• Rust changed, not Python. Python is the incumbent writer, so every live cache entry already holds Python's ordering. Moving Python to Rust's order would rewrite every team's cache instead.
• DISTINCT rather than ORDER BY ctx.name, so both sides run the identical construct and match by construction. The explicit sort looks stricter, but it would only go on the Rust side: four Python sites use the bare ArrayAgg(..., distinct=True). If Postgres ever stopped sorting for aggregate DISTINCT, identical constructs break together and both tests go red, whereas a one-sided ORDER BY would leave Rust sorted and Python not.
• No user-visible change. The Rust builder does not write the cache that serves flags.
• The rest of the diff is comments and test assertions.

How did you test this code?

• Rust: test_fetch_flags_with_evaluation_tags_from_pg now asserts the exact array. It already inserted three contexts out of alphabetical order, but asserted membership with contains, so no ordering bug could fail it. On the old aggregate it fails with left ["docs-page", "marketing-site", "app"] against right ["app", "docs-page", "marketing-site"].
• Python: test_verify_cache_detects_evaluation_context_rename moves from one evaluation context to two, created out of alphabetical order. The single-element array it used could not vary in order. This case passes before and after, because the Python aggregate is unchanged. It catches a later removal of distinct=True, which would split the two builders again.
• Not checked: 16 tests in cargo test -p feature-flags fail locally before this change as well. They need a GeoIP database file and a cohort_membership table the local database does not have. None reach this code path.
• No manual testing against a running app. The change is a background cache builder with no UI surface.

Automatic notifications

• Publish to changelog?

Docs update

None. No documented behavior changes.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Claude Code worked from a written brief that fixed the scope, the direction of the fix, and the build and test commands.

Skills invoked: /writing-tests, /writing-code-comments, /writing-pr-descriptions, /review-code --fix.

Two decisions are worth a reviewer's attention. The brief called for extending the Python test at test_flags_cache.py, but that test cannot fail before the change, because it never runs the Rust query. The failing test is therefore the Rust one, and the Python case is widened only to pin the reference ordering. Separately, the review pass proposed an explicit ORDER BY inside the aggregate; the Changes section records why that was declined.

The review pass also corrected a comment that named one Python builder when there are two. flags_hypercache registers both a load_fn and a batch_load_fn, and the single-team path in products/feature_flags/backend/models/feature_flag.py carries a second copy of the same ArrayAgg. That copy is the one the cache verifier compares against.

Follow-up not taken here: the same ArrayAgg(..., distinct=True) is hand-rolled at four Python sites. A shared helper would give the Rust comment one symbol to point at, but it touches files this change does not otherwise edit.

[trunk-io]

😎 Merged successfully - details.

[github-actions]

🤖 CI report

⚠️ Trunk lane — backend Python lane

This PR is assigned to the backend Python lane. It runs backend Python tests and may merge in parallel with PRs in other lanes.

[greptile-apps]

_{Reviews (1): Last reviewed commit: "fix(flags): sort evaluation contexts in ..." | Re-trigger Greptile}

[trunk-io]

   

View Full Report ↗︎ ⋅ Docs

[posthog]

🦔 PostHog Review reviewed this pull request

Nothing worth raising this time, so here's a calming picture instead:

[stamphog]

Approved.

Small, contained SQL fix aligning Rust's array aggregation with Python's existing sorted behavior in a cache-verification path with no production write path; author is on the owning team and tests were updated to pin the new behavior.

• Author wrote 0% of the modified lines and has 8 merged PRs in these paths (familiarity MODERATE).
• 👍 on the PR from greptile-apps[bot].

Gate mechanics and policy version

Gate		Result
prerequisites	✓	all clear
deny-list	✓	no deny categories matched
size	✓	17L, 1F substantive, 30L/2F incl. docs/generated/snapshots — within ceiling
tier	✓	T1-agent / T1b-small (30L, 2F, two-areas, fix)
stamphog 2.0.0b4		.stamphog/policy.yml @ fbfdf40 · reviewed head fbfdf40

[JamesPatrickGill]

/trunk merge

[deployment-status-posthog]

Deploy status

Environment	Status	Deployed At	Workflow
dev	✅ Deployed	2026-09-02 09:05 UTC	Run
prod-us	✅ Deployed	2026-09-02 09:15 UTC	Run
prod-eu	✅ Deployed	2026-09-02 09:16 UTC	Run