A role-grant test depends on which role comes back first

an_approved_role_request_is_granted_once, in projects/ores.iam/core/tests/role_grant_applier_tests.cpp, reads the tenant's roles and takes all.front() as the role it grants. It then asserts that a freshly seeded account does not already hold that role. The assertion is about whichever role the read returns first, not about a role the test chose, so it holds or fails with that ordering.

Seen on 2026-10-09: the IAM core suite failed once on REQUIRE_FALSE(holds(h, asker, role_id)) and passed on the next run over the same database, with Catch2 seeding a different order each time. A freshly seeded account carries a default role, so when all.front() is that role the test's own precondition is false before it has done anything.

The suite is therefore not deterministic, and a real failure in this test would be hard to tell from the flake. The fix is to name the role the test grants, or to assert on the difference the grant makes rather than on the state before it.

• projects/ores.iam/core/tests/role_grant_applier_tests.cpp, the test.
• Found while running the suite for Refuse a reporting line that would make a loop; the change under test touches the account's reporting line and cannot affect a role grant.

• User Journeys — the catalogue the task that found this belongs to.