Stale account ID cache after changing API credentials in settings form
When an administrator updates the Conductor API credentials (e.g. rotates an API key, switches to a Bearer token, or changes to a different Conductor account) via `/admin/config/services/conductor`, the previously resolved Conductor account ID remains cached. All subsequent API calls — draft creation, draft listing, deletion — continue using the stale account ID until the cache naturally expires. This can silently cause: * API requests hitting the wrong Conductor account when credentials are switched between accounts * Draft operations failing with unexpected errors if the old account ID is no longer valid under the new credentials **Root Cause:** getAccountId() caches the resolved Conductor account ID using the tag `conductor_api:account_id`: ``` $this->cache->set($cid, $accounts[0]['accountId'], tags: [ 'conductor_api:account_id', // ← shared tag across all users 'user:' . $this->currentUser->id(), ]); ``` Without invalidation, changing the configured key — whether rotating credentials or switching to a different Conductor account — leaves every user's cached account ID pointing at the old account until natural cache expiry.
issue