[4.x] Make globalCache always use the central connection with database cache store#1462
[4.x] Make globalCache always use the central connection with database cache store#1462lukinovec wants to merge 4 commits into
globalCache always use the central connection with database cache store#1462Conversation
📝 WalkthroughWalkthroughAdds a helper called during the ChangesDatabase Cache Connection Centralization
🎯 3 (Moderate) | ⏱️ ~20 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
lukinovec
changed the title
globalCache always use the central connection
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1462 +/- ##
============================================
+ Coverage 85.90% 85.94% +0.04%
- Complexity 1170 1174 +4
============================================
Files 185 185
Lines 3412 3422 +10
============================================
+ Hits 2931 2941 +10
Misses 481 481 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/TenancyServiceProvider.php`:
- Around line 127-140: The loop eagerly instantiates every database cache store
by calling $manager->store($name)->getStore(), causing unnecessary connections;
instead, avoid materialization by registering a lazy decorator for each
configured database store using $manager->extend($name, ...), and inside that
extender wrap/return the real store and call setConnection(...) and
setLockConnection(...) on the DatabaseStore using $store['connection'] ??
$centralConnection and $store['lock_connection'] ?? $store['connection'] ??
$centralConnection so the central-connection fallback is applied only when a
store is actually resolved; reference $manager->extend, DatabaseStore,
setConnection, setLockConnection, $store and $centralConnection to locate and
implement the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: e78e02ab-9f44-436e-9714-85a7f2f2445b
📒 Files selected for processing (3)
src/TenancyServiceProvider.phptests/CachedTenantResolverTest.phptests/GlobalCacheTest.php
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@tests/CachedTenantResolverTest.php`:
- Line 168: The dataset leaves TenancyServiceProvider::$adjustCacheManagerUsing
mutated by the DatabaseTenancyBootstrapper case so the subsequent
CacheTenancyBootstrapper case inherits the callback; update the test fixture in
CachedTenantResolverTest (in the beforeEach/afterEach surrounding the dataset)
to explicitly reset TenancyServiceProvider::$adjustCacheManagerUsing to its
known default (e.g., null or the original default closure) in addition to the
existing Tenant::$extraCustomColumns reset so each case exercises
makeDatabaseCacheStoresCentral() independently.
In `@tests/GlobalCacheTest.php`:
- Line 168: Tests leave TenancyServiceProvider::$adjustCacheManagerUsing set by
DatabaseTenancyBootstrapper, causing stale static state that affects later
CacheTenancyBootstrapper assertions; reset the static between runs by explicitly
assigning the class default (e.g.
TenancyServiceProvider::$adjustCacheManagerUsing = null or the original default)
in the test suite setup/teardown (beforeEach()/afterEach()) in the
GlobalCacheTest so each test starts with a clean
TenancyServiceProvider::$adjustCacheManagerUsing state.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 574ac1d9-33d8-4426-852f-0208fe2e5108
📒 Files selected for processing (3)
src/TenancyServiceProvider.phptests/CachedTenantResolverTest.phptests/GlobalCacheTest.php
There was a problem hiding this comment.
Pull request overview
This PR fixes globalCache behavior so that database-backed cache stores use the central (or explicitly configured) DB connection even when the app is currently in tenant context (notably when using DatabaseTenancyBootstrapper + CacheTenancyBootstrapper). This prevents global cache reads/writes and cache invalidation from accidentally targeting tenant databases.
Changes:
- Adjust
globalCache’s freshly-instantiatedCacheManagerto reset database cache stores onto the central/configured connection. - Add regression coverage for the database cache driver when used with
CacheTenancyBootstrapper. - Reset
TenancyServiceProvider::$adjustCacheManagerUsingin tests to avoid cross-test state leakage.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/TenancyServiceProvider.php |
Ensures database cache stores on the globalCache manager are pointed at the central/configured DB connection. |
tests/GlobalCacheTest.php |
Adds regression dataset for database cache + CacheTenancyBootstrapper and resets the static cache-manager adjuster between tests. |
tests/CachedTenantResolverTest.php |
Adds regression dataset for database cache + CacheTenancyBootstrapper and resets the static cache-manager adjuster between tests. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
lukinovec
changed the title
globalCache always use the central connectionglobalCache always use the central connection with database cache store
globalCacheshould always use the central connection, but when using adatabase-driver cache store withDatabaseTenancyBootstrapper, it does not (with the exception ofDatabaseCacheBootstrapper, explained below).globalCachecreates a freshCacheManagereach time it's resolved (it's abind, not asingleton). A freshly-created manager builds its database stores using the current default DB connection. WhenDatabaseTenancyBootstrapperis active, that default istenant. SoglobalCachein tenant context points at the tenant DB. Specifically,CachedTenantResolverstores cached tenant lookups viaglobalCache. When a domain is deleted in tenant context, the invalidation logic callsglobalCache->forget(...), but that hits the tenant DB, while the resolver cache entry is in the central DB.globalCache->forget(...)doesn't actually do anything in that case.With
DatabaseCacheBootstrapper, this is already handled.globalCacheis always central because it setsTenancyServiceProvider::$adjustCacheManagerUsingto a callback that explicitly restores the central connection onglobalCache's stores.To fix this, after constructing the fresh CacheManager in the globalCache binding, explicitly set the connection of every database-driver store to its configured connection value, falling back to central_connection when the config value is null (null value = inherits whatever the current default DB connection is).
This is sufficient for
CacheTenancyBootstrapperand any other bootstrapper that doesn't explicitly set the store's DB connection. ForDatabaseCacheBootstrapperspecifically, this alone is not enough since it explicitly sets the store's config connection to 'tenant'. That's why DatabaseCacheBootstrapper's$adjustCacheManagerUsingcallback runs after and overrides those stores back to the original (central) connection.Added datasets that use the database cache store + CacheTenancyBootstrapper to the relevant tests (globalCache and invalidation) to test regression (0cf7043), and the changes mentioned above (5e65c67) make these tests pass.
Summary by CodeRabbit
Bug Fixes
Tests