v1.6.57

[roncodes]

Ready for immediate release: version bumped, RELEASE.md written, so merging this tags v1.6.57 and publishes automatically.

The bug

Writing a system setting did not clear the cache entry Setting::system() reads, so the old value kept being served until the cache was cleared by hand.

system() caches under 'system_settings.' . $key using the key exactly as the caller passed it — configureSystem('platform_api.token_hash') reads back system_settings.platform_api.token_hash. The row, though, is stored as system.platform_api.token_hash, and the saved/deleted events built the cache key from the row:

writes/reads:  system_settings.platform_api.token_hash
event forgot:  system_settings.system.platform_api.token_hash   ← nothing ever writes this

clearSystemCache() looked like it covered the gap, but it pattern-clears through Redis and api/.env.example ships CACHE_DRIVER=file — so on a default install neither path invalidated anything.

How it surfaced

The API contract run's minted platform token was rejected with {"errors":["Invalid platform API token."]}. The seed rotated the token and wrote the new hash; every request kept validating against the previously cached one. It is the only failing assertion in fleetops#295's otherwise-clean run, and nothing in that PR caused it.

I reproduced it by forcing the file driver on a live stack — with redis it passes, which is why it never reproduced locally.

Also fixed

clearCacheByPattern() resolved a Redis connection unguarded, and the saved event calls through it — so on an install with no Redis configured, an ordinary Setting::configureSystem() write raised a binding exception. Pattern clearing is inherently Redis-only; without Redis there is nothing to enumerate, so it now skips rather than fails.

Verification

The regression test asserts behaviour, not implementation — write, read, write again, read again. I checked it fails against the old event handler and passes with the fix, so it is a real guard rather than a passing test.

Full suite: 1418 passed, 0 failures. That includes SettingControllerExternalProbesTest, the Sentry DSN test that was red on main.

Known limitation, stated rather than hidden

Utils::clearCacheByPattern() still only clears entries on Redis. That no longer matters for settings, which now invalidate their own keys directly, but a caller relying on pattern clearing for something else will not see it work on another driver.

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (b85c27f) to head (f067bf8).

Additional details and impacted files

@@             Coverage Diff             @@
##                main      #240   +/-   ##
===========================================
  Coverage     100.00%   100.00%           
- Complexity      6727      6730    +3     
===========================================
  Files            397       397           
  Lines          22442     22447    +5     
===========================================
+ Hits           22442     22447    +5     

Flag	Coverage Δ
backend	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.