[andreasarf]

Summary

Second of three Redis PRs, stacked on #14 (cache). Merge #14 first; GitHub then retargets this PR to main.

• Redisson client. It uses the plain org.redisson:redisson 4.8.0 library. Its Spring Boot starter is built against Boot 3.5 and Boot 4 moved the Redis auto-configuration, so the starter isn't used.
  • Same Redis as the cache. It connects with Boot's DataRedisConnectionDetails and the same timeouts, so Docker Compose and Testcontainers connections work too.
  • Lazy connection. It connects on first use, so the app, including the AOT training run during docker build, starts without Redis.
  • Prefixed names. Object names get resourceapi.redisson.key-prefix.
• ProjectSyncLock. POST /api/v2/projects/{id}/sync takes a per-project RLock (project-sync:{id}). A second sync of the same project, from any instance, gets 409 until the first ends.
  • Release. The lock is released when the background sync's future completes, or right away if the task executor rejects the sync.
  • Owner. The lock is held by a random owner ID, not the request thread, because it is released on the background thread.
  • Lease. It expires after resourceapi.sync.lock-lease-time (60 s) if never released, e.g. when an instance dies.
  • Redis down. The sync runs without the lock and a warning is logged: a duplicate sync only costs an extra SDLC call, while refusing would stop syncs entirely.
• spring.cache.type=redis. Redisson brings a JCache provider (javax.cache:cache-api), and Boot prefers JCache over Redis when choosing the cache. Without this setting, every cache call failed with "Cannot find cache named 'sdlc-systems'".

Tests (real Redis)

• ProjectSyncLockIntegrationTest:
  • lock held by "another instance" gives 409 and no SDLC call; once released, sync works again;
  • slow sync: the second POST gets 409, and the lock is free within 500 ms of the first sync ending, long before its lease;
  • an abandoned lock expires after its lease;
  • lock keys carry the test context's prefix.
• CacheUnavailableTest: with Redis down, a sync still runs and completes.
• ProjectSyncBackpressureTest: now uses two projects, because the lock refuses the same project before the executor limit applies. It also checks that a rejected sync released its lock.
• Mutation checks. Each was checked to fail with its fix removed: the release when a sync ends (the first version of the test didn't catch that, because the short lease expired in time; fixed with a 30 s app lease in the test) and the fail-open handling.

Full suite: 95 tests pass.

---

Generated by Claude Code