The resolver tracks why it has no value. It only uses the environment fallback for the legacy default org, and only after a successful read positively confirmed that no stored credentials exist. Transient read failures are never cached, so a blip cannot pin an empty result for the full TTL.
Also called: wrong company's data · tenant isolation · shows the wrong deals
- 1A stored-credentials read either succeeds, fails transiently, or returns an undecryptable blob.
- 2readFailed and storedCredsPresent flags record which happened.
- 3The env fallback is allowed only when neither flag is set.
- 4A transient failure is not written to the cache.
The comment names the consequence directly: 'The env-var location is a different GHL identity than any tenant's stored location — silently serving it when a stored read merely blipped (or the blob was unreadable) shows the WRONG company's deals and makes pipeline card moves snap back, because writes land in a location the next poll doesn't read from.' A separate note records the race the lazy client fixed: a module-level client evaluated before .env.local loaded stayed null for the process's whole life, so 'a tenant saw the WRONG GHL location until the server was restarted.'
- A transient database blip could show one tenant another tenant's CRM data.
- Writes landing in the wrong CRM location made board moves appear to revert.
- An import-time race left credentials permanently unresolvable for a process.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →