Drop this customer's cached reads.
Lives here rather than on the writer because it's the cache's own
concern — it names the folded-get keys and the customer tag — so both
the reader (CustomerQueryService) and the writer (CustomerService)
inherit it. The actual caller is customerOnboardingActivities
(@cfxlabsinc/onboarding-services), which calls this once a primary
organization exists for the customer: a customer is invisible to
get/search until its primary org exists, so every read taken earlier
in onboarding cached a negative entry with a 24h L2 TTL, and this is what
clears it.
Bust every cached page — consumer or admin — that a write touching
customerIds could have affected.
The collection tag is always cleared alongside, because an unscoped admin page carries only that tag and no customer id can reach it.
keys deletes exact entries in addition to the tag surgery, passing the
key arguments — this cache hashes and prefixes them. It exists because
invalidateTag resolves keys through the FT index, which does not exist in
memory mode (valkeyClient: null); there the tag bust is a total no-op, and
an exact-key delete is the only thing that keeps read-after-write honest.
Services that folded get onto search pass that get's arguments.
These deletes only reach this instance's own key space, because the key space is partitioned per surface. That is sufficient, and a writer must not try to name the other surface's key:
get entry is itself tagged (by customer
id, or by the collection tag when unscoped), so the tag bust above already
evicts it from the shared L2 and publishes the peer eviction.ProtectedsearchTags to write on a page, derived from the scope the query searched — never from the customers present in the result.
That distinction is load-bearing. An entry tagged with the customer ids in
the page carries no tags when the page is empty, so nothing can ever bust
it and a later create leaves it stale for the full L2 TTL. Tagging by
scope means an empty page still carries the tag for what it searched.
An unscoped read falls back to the collection tag, since no customer-id tag can reach a row whose owner did not exist when the entry was written.
StaticdeserializeThe inverse of serializeCustomer: rehydrates the Date fields.
StaticgetAs getCacheKey, for the get({ propelauthWorkspaceId }) fold.
StaticgetThe exact cache key CustomerQueryService.get({ id }) reads through.
get folds onto search, so its entry is an ordinary single-row search
page — these args must stay identical to the ones get passes
({ ids: [id], pageSize: 1 }, plus search's page default of 1). Every
other filter is undefined there, and serviceCacheKey canonicalizes with
JCS, which drops undefined properties, so naming only the three that are
set produces the same digest. customerCache.test.ts pins the equivalence.
Returns the key arguments; the cache hashes and surface-prefixes them. Never pre-hash at a call site.
StaticserializeCustomer → its JSON-safe form. Safe to call without a Valkey client.
Root of the customer class hierarchy: owns the one
customer-searchcache, the seam that busts it, and the serialization that defines the cached shape.Customer has a single read surface —
CustomerServicehas always served both consumer and admin callers — so there is onekeyPrefix,"customer".