But DB cleanup only covers SQL (DatabaseCleaner), while the model writes one Redis key per authorization (authorizations:#{user.cn}:#{token}). Redis keys therefore accumulate across examples and spec files, and the example did not even create the authorization it asserted on — it relied on a previously-run example leaving exactly one key.
This made the spec pass or fail depending on test/file order and leftover Redis state. It failed on CI with got: 5 (unrelated to the change in the failing PR); locally it can pass.
Fix
In the #create group:
clear the authorizations:* namespace before each example, and
create the authorization under test and assert on its specific token key instead of a global count.
Testing
Spec in isolation → 18 examples, 0 failures.
Simulated the CI condition by pre-seeding 5 stale authorizations:jimmy:* keys → spec now passes (previously got: 6).
Full suite → 298 examples, 0 failures.
## Problem
`RemoteStorageAuthorization#create > stores a token in redis` (spec line 29) asserted an exact count of Redis keys for the user:
```ruby
user_auth_keys = redis_rs.keys("authorizations:#{user.cn}:*")
expect(user_auth_keys.length).to eq(1)
```
But DB cleanup only covers SQL (DatabaseCleaner), while the model writes one Redis key per authorization (`authorizations:#{user.cn}:#{token}`). Redis keys therefore accumulate across examples and spec files, and the example did not even create the authorization it asserted on — it relied on a previously-run example leaving exactly one key.
This made the spec pass or fail depending on test/file order and leftover Redis state. It failed on CI with `got: 5` (unrelated to the change in the failing PR); locally it can pass.
## Fix
In the `#create` group:
- clear the `authorizations:*` namespace before each example, and
- create the authorization under test and assert on its specific token key instead of a global count.
## Testing
- Spec in isolation → 18 examples, 0 failures.
- Simulated the CI condition by pre-seeding 5 stale `authorizations:jimmy:*` keys → spec now passes (previously `got: 6`).
- Full suite → 298 examples, 0 failures.
"stores a token in redis" asserted an exact count of Redis keys for the
user, but database cleanup only covers SQL and Redis keys accumulate
across examples and spec files. It also relied on a previously-run
example having created the authorization, so it failed depending on test
order and leftover state.
Clear the authorizations:* namespace before each example in the #create
group, create the authorization under test, and assert on its specific
token key instead of a global count.
raucao
added the bug label 2026-10-06 13:36:06 +00:00
raucao
merged commit d8bba02636 into master2026-10-06 13:36:21 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
RemoteStorageAuthorization#create > stores a token in redis(spec line 29) asserted an exact count of Redis keys for the user:But DB cleanup only covers SQL (DatabaseCleaner), while the model writes one Redis key per authorization (
authorizations:#{user.cn}:#{token}). Redis keys therefore accumulate across examples and spec files, and the example did not even create the authorization it asserted on — it relied on a previously-run example leaving exactly one key.This made the spec pass or fail depending on test/file order and leftover Redis state. It failed on CI with
got: 5(unrelated to the change in the failing PR); locally it can pass.Fix
In the
#creategroup:authorizations:*namespace before each example, andTesting
authorizations:jimmy:*keys → spec now passes (previouslygot: 6).