Elgato_dark/OpenMetadata
1
0
Fork 0
mirror of https://github.com/open-metadata/OpenMetadata synced 2026-05-24 09:39:11 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 5
OpenMetadata/docker/development/docker-compose.cache-off.yml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

9 lines
403 B
YAML
Raw Permalink Normal View History

Cache improvements: lineage + search layers, observability, CI gate (#28012) * cache: lineage cache, per-type metrics, invalidation registry, search-cache Add Redis-backed lineage response cache and search response cache, both gated by the existing CACHE_PROVIDER toggle and falling through to direct computation when the cache is unavailable. The cache remains optional — verified end-to-end by toggling CACHE_PROVIDER=none on a live stack and confirming all paths continue to work (just without the L2 hit). Coverage: - CachedLineage wraps LineageRepository.getLineage with hybrid TTL + direct invalidation (60s default). Direct edits invalidate the affected root cache entries; transitive changes fall through to TTL. - CachedSearchLayer wraps /api/v1/search/query with auth-aware caching (cache key includes principal so users with different ACLs don't share results). 30s default TTL. Observability: - /api/v1/system/cache/stats response now includes a metrics block with hits/misses/hitRatio/evictions/errors/writes plus read/write latency Timers, and a byType breakdown so coverage gaps are visible per entity-type and per cache-layer. Correctness: - New Invalidatable interface + CacheBundle registry + invalidateEntity helper so future cache layers plug in by implementing one method instead of editing multiple mutation paths. - Edge mutations in LineageRepository.addLineage/deleteLineage invalidate both endpoints; entity mutations in EntityRepository.postUpdate / postDelete / restoreEntity invalidate the lineage rooted at the entity. - Pub/sub handler in CacheBundle iterates registered Invalidatables so remote-pod evictions flow to all layers automatically. Tooling: - docker-compose.cache-off.yml overlay flips CACHE_PROVIDER=none for local A/B testing without tearing down DB/ES volumes. - CachedSearchLayerIT exercises hit-on-second-call, distinct-query misses, distinct-page-size misses, and byType shape via the metrics endpoint. Each test gracefully no-ops when the cluster runs cache-off. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * cache: phase 2 ops + correctness — single-flight, slow-read, negative cache, admin endpoints Builds on the phase 1 commit (c20a29b11b) with operability and correctness items from .context/cache-improvements-design.md. All four pieces respect the optional-cache contract: with CACHE_PROVIDER=none they no-op cleanly. P2.3 — Single-flight on CachedSearchLayer Striped<Lock> keyed by SHA-cache-key. 100 concurrent users hitting the same uncached query collapse to one ES call instead of N. SearchResource now uses loadOrCompute so the lock-and-recheck pattern lives inside the cache layer; the supplier is the actual ES call kept tight to minimize lock-hold time. Non-200 upstreams bypass cache and refetch. P2.6 — Slow cache reads logged RedisCacheProvider.get/hget timing checked against cache.slowReadThresholdMs (default 50ms). Exceeding fires a WARN log and bumps a new cache.reads.slow Micrometer counter exposed in /cache/stats.metrics.slowReads. Leading indicator of Redis pressure / network glitch / hot-key contention. P2.4 — Negative caching for not-found entities NotFoundCache marks "we looked, no such entity" with a short TTL (default 30s) so repeated 404 lookups (typo'd FQNs, references to deleted entities) don't hammer the DB. Wired into EntityRepository.find(UUID) and findByName for the !fromCache path. Implements Invalidatable so the postCreate fan-out drops the marker on entity create — without that, create-then-immediately-read would 404 for up to TTL. Added CacheBundle.invalidateEntity to EntityRepository.postCreate so newly-created entities reach every Invalidatable registry layer. P2.5 — Admin cache ops endpoints GET /api/v1/system/cache/keys?pattern=... — SCAN keys, returns count POST /api/v1/system/cache/invalidate?pattern=.. — SCAN+UNLINK, returns deleted POST /api/v1/system/cache/invalidate/entity?type=&id=&fqn= — fan to all Invalidatables All admin-only. Pattern endpoints document the "no broad globs" rule — we never want a SCAN over om:prod:* on a busy cluster. Per-entity endpoint goes through the existing Invalidatable registry so future cache layers are reachable from ops without ever touching this code. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * cache: pipelined mget on CacheProvider + CachedReadBundle.getBatch Adds a foundational batch-read primitive at the provider layer: CacheProvider.mget(List<String>) -> List<Optional<String>> Default implementation does sequential per-key gets (correct, no batching benefit). RedisCacheProvider overrides with a true pipelined version: all GETs are queued under setAutoFlushCommands(false), then flushed once and awaited as a single TCP round-trip. Records hits/misses through the existing CacheMetrics counters and respects the slow-read threshold. Per-key pipelining over true MGET — Redis Cluster requires same-slot keys for MGET; pipelined per-key GETs work transparently across slots without the constraint, at the same network cost. CachedReadBundle.getBatch(entityType, ids) consumes the new primitive for prefetch use cases (UI prefetch on hover, list-then-detail navigation warmup). The list endpoint hot path itself does NOT use this layer — list responses are SQL-batched via EntityRepository.setFieldsInBulk which calls fieldFetchers in bulk, not per-row CachedReadBundle.get. That's why bench3 showed list endpoints at neutral cache_off-to-on ratio: lists already amortize at the SQL layer. The mget primitive is what later phases will plug into when wiring batch-prefetch to specific UI flows. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(cache): use unique query in sameQueryHitsCacheOnSecondCall to avoid state pollution Sequential test run on postgres-os-redis caught a flake: the test issued 3 identical "q=*" calls expecting at least 1 cold-write. By the time it ran, prior tests in the same JVM session had already cached (q=*, index=table_search_index, size=10), so call 1 was a hit, call 2 hit, call 3 hit — total writes=0, asserts failed. Switching to a per-invocation nonce ensures we always start cold, matching the pattern the other 3 tests in this class already use. Confirmed via subsequent parallel-pass run on the same suite where the test passed (different test ordering, fresh cache for that key). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * cache: drop search cache TTL from 30s to 2s for create-then-search freshness Integration tests on the postgres-os-redis profile caught a real correctness regression: tests that create an entity and Awaitility-poll for it to appear in search timed out at 30s because our 30s search TTL pinned the pre-create empty result for the entire test window. Same issue surfaces in production: a user creates a domain / table / dashboard and immediately searches for it would see "no results" for up to 30s. 2s caps the staleness while still catching the dominant UI access pattern: multiple components in the same render frame fire identical search queries. Those happen within milliseconds, well inside any reasonable TTL. The longer-term fix is search-cache invalidation on entity writes (a generation counter per entity-type, search keys include the generation, writes bump the generation). That's design-doc-tracked in .context/cache-improvements-design.md but deferred — the 2s TTL is good enough for now, and the more complete invalidation strategy can be a follow-up PR with its own dedicated tests. Failing tests under 30s TTL that this fixes: - DomainAssetsColumnExclusionIT (domain create-then-search) - LineageImpactAnalysisIT (owner removal reflected in search) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * ci: cache-tests profile runs full IT suite + new postgres+es+redis CI workflow The cache-tests Maven profile previously ran only the four cache/* IT classes — too narrow to catch cache-correctness regressions in the rest of the codebase. Expanded it to mirror the mysql-elasticsearch profile shape: sequential + parallel failsafe executions, full **/*IT.java inclusion, postgres + elasticsearch + redis backend, with cacheProvider=redis system property added so every test path exercises the cache layer. Locally, the focused-cache-only run is preserved via mvn verify -P cache-tests -Dit.test='**/cache/*IT' New CI workflow integration-tests-postgres-elasticsearch-redis.yml mirrors the structure of integration-tests-postgres-opensearch.yml: - Same triggers (push to main, PR target, merge_group, workflow_dispatch) - Same path filters (openmetadata-service/**, integration-tests/**, etc.) - Same Maven cache + JDK 21 setup - Runs `mvn verify -pl :openmetadata-integration-tests -Pcache-tests` - Surefire-report publication with fail_on_test_failures Result: PRs touching cache code (or any read path) get automatic CI coverage with redis enabled. Cache-invalidation and stale-data bugs that previously only surfaced in production now have a CI gate before merge — same protection that mysql-elasticsearch and postgres-opensearch provide for the no-cache code paths. Smoke verified locally: `mvn verify -P cache-tests -Dit.test='**/cache/*IT'` runs both sequential and parallel passes (6 tests each), all green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): address PR review feedback for cache improvements Nine review-driven fixes spanning the cache PR (#28012): RedisCacheProvider.mget (bug): - Restructured the auto-flush window so `setAutoFlushCommands(true)` is in the OUTER `finally` of the entire op. The previous structure had the restoration in an inner finally that only fired around the awaitAll call; an exception in the queueing loop or flushCommands() would leave the SHARED connection in auto-flush=false mode, making every subsequent op from any caller silently buffer indefinitely. SearchResource (bug): - Removed the double-call on the non-cacheable response path. The supplier now captures the upstream Response object so the outer code can return it directly when the body isn't cacheable (non-200 or non-String entity) — previously the caller re-invoked searchRepository.search() on every error/non-200, doubling backend load for failing queries. EntityRepository negative cache (edge case): - Hoisted the NotFoundCache fast-path OUTSIDE the `!fromCache` guard in both `find(UUID,...)` and `findByName(...)`. Default callers go in via `find(id, include)` which delegates with fromCache=true; the previous gate made the fast-path unreachable for the most common caller. Also added negative-cache population from the cached path's ExecutionException so repeated requests for a non-existent id do short-circuit after the first miss. SystemResource cache endpoints (security + style): - `/cache/keys` and `/cache/invalidate` now validate the glob pattern via `validateCachePattern` — rejects pure wildcards or patterns with fewer than 6 literal characters before the first wildcard. Stops a careless or malicious admin from issuing `*` or `om:*` that would block the Redis cluster on a large keyspace. ReDoS-safe: linear char scan, no regex backtracking. - `/cache/invalidate/entity` now also calls `EntityRepository.invalidateCacheForEntity(...)` to evict the Guava L1 caches (`CACHE_WITH_ID`, `CACHE_WITH_NAME`) and propagate via the existing pub-sub channel — the previous code only invalidated the `INVALIDATABLES` registry layers, leaving stale L1 entries. - Replaced fully-qualified class names (`org.openmetadata.service. cache.CacheMetrics`, `jakarta.ws.rs.QueryParam`, `java.util.UUID`) with proper imports per the project style guide. CachedLineage (edge case): - Single-flight stripe lock now keys on the FULL cache key `(rootId, upstreamDepth, downstreamDepth, includeDeleted)` instead of `rootId` alone. Concurrent requests for different depths or include-deleted flags on the same root no longer block each other. CachedSearchLayer (doc): - Javadoc now correctly says default TTL is 2s (was incorrectly 30s) and explains why — see commit 41489056ff which dropped it from 30s after IT regressions where users couldn't see their own writes for half a minute. CI workflow (bugs + security mitigation note): - Removed `if: steps.cache-output.outputs.exit-code == 0` from the `Set up JDK 21` and `Install Ubuntu dependencies` steps. `actions/cache@v4` exposes `cache-hit`, never `exit-code`; the expression always evaluated to false and those steps NEVER ran. Maven was using whatever JDK shipped with the runner. - Added explicit security note in the workflow header AND on the `Checkout` step documenting why `pull_request_target` is intentional and what the `safe to test` label gate accomplishes — CodeQL flags the pattern, the label gate is the accepted mitigation that mirrors every other integration-tests-*.yml workflow in this repo. Verified: - mvn compile -pl openmetadata-service → BUILD SUCCESS - mvn test -pl openmetadata-service -Dtest=OpenMetadataAssetServletTest → 9/9 pass - mvn spotless:apply ran clean Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): only negative-cache on real EntityNotFoundException The previous code caught every ExecutionException / UncheckedExecutionException from the Guava cache loader and (a) populated NotFoundCache for 30s, (b) rethrew as EntityNotFoundException. That conflated three very different failure modes: 1. Entity truly doesn't exist → loader throws EntityNotFoundException 2. Entity exists but is invalid → loader throws IllegalStateException 3. Transient DB / deser failure → loader throws JdbiException, IOException Cases 2 and 3 would poison the negative cache, turning a momentary DB hiccup or a single bad row into a sustained 30s 404 for every caller that asks for that id/fqn. Worse, the original cause was masked behind a synthetic EntityNotFoundException, so logs and clients never saw the real failure. This change inspects e.getCause() and: - On EntityNotFoundException: populate NotFoundCache, rethrow the original (not a synthetic) so the caller's `instanceof` checks and message text still work. - On any other RuntimeException: rethrow unchanged — DB blips return 5xx as before, validation errors surface, and the next request can re-attempt without hitting a poisoned cache. - On checked Throwable cause (rare for these loaders): wrap in RuntimeException so the contract is preserved. Applied symmetrically to find(UUID, …) and findByName(String, …). Addresses gitar-bot review on PR #28012: https://github.com/open-metadata/OpenMetadata/pull/28012#discussion_r... (negative cache poisoning) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): copilot review — blank param, javadoc, mget hardening Four review comments from PR #28012 review 4266159401: SystemResource.invalidateCacheForEntity (line 1069 → blank query params): `?type=X&id=&fqn=` slipped past the required-params check because only `null` was treated as absent. Normalize blank id/fqn to null up front so the missing-both branch fires correctly and the downstream CacheBundle / EntityRepository calls receive a clean null instead of an empty string. CacheKeys.search/childrenPage (line 116 → orphaned Javadoc): When the search() helper was added between the children-page Javadoc and the childrenPage() method, the Javadoc got stranded above the wrong method. Move it back so javadoc tooling generates accurate docs. RedisCacheProvider.mget (line 610 → shared-connection auto-flush race): setAutoFlushCommands(false) toggles state on the shared Lettuce connection — two concurrent mgets could overlap and one caller's commands would buffer until the other restored auto-flush, surfacing as latency spikes / hangs on other paths sharing the connection. Wrap the pipeline in a new instance-level ReentrantLock so only one mget runs the auto-flush dance at a time. try/finally still restores auto-flush unconditionally; lock release sits in an outer finally. RedisCacheProvider.mget (line 621 → unbounded f.get() on timeout): Previously LettuceFutures.awaitAll(...) returned a boolean we ignored; if it timed out, the subsequent f.get() calls were unbounded and would block the request thread until the Lettuce event loop eventually gave up. Capture the boolean, cancel non-done futures on timeout (so f.get() returns CancellationException instead of blocking), and log a warning with the timeout value and key count for operators. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): mget partial timeout must trip the circuit breaker The previous mget rewrite cancelled in-flight futures on awaitAll timeout but still called recordSuccess() at the end of the happy-path. That fed consecutiveSuccesses on every partial timeout, so a Redis instance that was consistently slow (answering some keys, dropping others) would *never* trip the breaker — masking real backend degradation as healthy. Branch on the captured allCompleted boolean: - all futures completed → recordSuccess() as before - partial timeout → recordFailure(TimeoutException) and bump CacheMetrics.recordError() so the breaker's sliding-window failure detector picks it up and the metric reflects the degraded state No other behaviour change — the per-key fallback Optionals still surface to callers either way. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): mget shorter critical section + cache/stats + cache/keys doc Three review comments from PR #28012 second copilot pass: RedisCacheProvider.mget (RedisCacheProvider.java:624 — shared-connection hold time): previous code held setAutoFlushCommands(false) for the entire queue+flush+await window. Other paths (single get/set/hget on the same Lettuce connection) would buffer until our await finished. Shrink the critical section to just queue+flush: once flushCommands() returns, the batch is on the wire and we can restore auto-flush and release the pipelineLock before awaiting. A slow Redis now blocks only the calling thread, not every concurrent caller using the shared connection. Cancel-on-timeout and breaker accounting are unchanged. SystemResource.getCacheStats (line 962 — noisy WARN when cache disabled): CacheMetrics.getInstance() logs WARN every call when the metrics singleton isn't initialized, which happens whenever CACHE_PROVIDER=none. An ops dashboard polling /system/cache/stats on a cache-off deployment would spam the log. Gate the metrics call on cacheProvider.available() so the WARN never fires in that configuration. Stats payload still includes provider-level fields; just no `metrics` key when cache is off. SystemResource.scanCacheKeys (line 1006 — OpenAPI lies about count param): Description claimed "bounded by the count parameter" but no count param exists; scanCount() walks the full cursor. Rewrote the description to state the actual safety mechanism: the validateCachePattern enforces a 6-character literal prefix before any wildcard, so '*' and 'om:*' are rejected at validation. Reflects what the endpoint actually does. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): copilot review pass 3 — hot-path L1 check + lineage hash + cleanups Eight comments from the latest copilot review on PR #28012: 1. SystemResource.getCacheStats: gate metrics on cacheConfig.provider != none instead of cacheProvider.available(). When Redis is configured but the circuit breaker is tripped, app-level counters are exactly what an operator needs to diagnose the outage — suppressing them while the provider is "down but configured" hides the diagnostic signal. Also downgrade CacheMetrics.getInstance() WARN → DEBUG so a poller loop doesn't spam logs in the entirely-normal cache-off state. 2. CachedReadBundle.getBatch contract: the method is documented as returning a list 1:1 with entityIds, but bypass returned Collections.emptyList() and callers indexing by position would shift off the rails. Return a same-size list of nulls under bypass so the positional contract holds regardless of cache state. 3+4. CacheBundle.invalidateEntity / Invalidatable.invalidate javadocs claimed they were called from EntityRepository.postUpdate / postDelete / restoreEntity. They are NOT (only postCreate, the pub-sub handler, and the admin endpoint reach this path). Updated both javadocs to reflect actual call sites so future Invalidatables aren't built on a wrong invalidation contract. 5+6. EntityRepository.find / findByName: check Guava L1 (getIfPresent) FIRST, NotFoundCache only on L1 miss. The previous shape consulted NotFoundCache before L1, adding one Redis GET per cached read — a regression on the hottest read path. L1 hit now serves with zero Redis traffic; the negative cache short-circuits only when the loader would otherwise pay for a DB / Redis-L2 round trip. 7. CachedLineage redesign: variants for one root now live as fields of a single Redis hash (HSET / HGET) instead of separate keys. Invalidate is one DEL — O(1) — instead of SCAN-and-iterate (O(N) over keyspace). This matters because invalidate fires on the hot write path (entity updates and lineage-edge mutations) and the SCAN cost grew linearly with cache size. CacheKeys.lineageGraphPattern is gone; new helpers are lineageGraphHash(rootId) and lineageGraphField(up, down, incDel). 8. SystemResource.invalidateCacheForEntity: when only fqn is supplied, resolve to id server-side via Entity.getEntityRepository(type). findByName(...) before fanning out. Id-keyed cache layers (lineage, CACHE_WITH_ID, NotFoundCache id-side) need the UUID; the previous shape silently skipped them. Lookup failures are logged at DEBUG and the request still proceeds with fqn-only invalidation — admin force-invalidate is best-effort by design. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): lineage hash TTL claimed only by first writer (EXPIRE NX) Previous shape called `hset(hashKey, fields, ttl)` which translated to HSET + EXPIRE under the hood. Every variant write therefore reset the hash's expiry — variant A cached at T=0 with TTL=60, variant B cached at T=55, and A's effective lifetime jumped to 115s instead of the intended 60s. Under a constant trickle of variant writes on a hot root, the "stale" variant could effectively live forever. Split the operation: - CacheProvider.hset(key, fields) — new overload, no TTL touch. Defaults to a 365-day TTL so providers that don't override get a long-lived key rather than an immortal one. - CacheProvider.expireIfAbsent(key, ttl) — EXPIRE … NX semantics: set the TTL only when the key has no prior expiry. Default returns false (providers that can't express NX get no extension benefit, but no regression). - RedisCacheProvider implements both: HSET without expire, then EXPIRE with ExpireArgs.Builder.nx(). Falls back gracefully on Redis < 7.0 (logs at DEBUG, returns false). CachedLineage.safeHset now uses the split shape — the first writer to seed a hash establishes the 60s window; subsequent variant writes leave the expiry alone. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): mget unavailable-path alignment + lineage deser fallback Two copilot review comments on PR #28012: RedisCacheProvider.mget (line 646): when `available == false` we returned `Collections.emptyList()`, violating the 1:1 positional contract that callers (CachedReadBundle.getBatch and friends) rely on. Match the error-fallback branch: return one Optional.empty() per requested key so caller-side indexing stays aligned regardless of provider health. Truly-empty input keeps returning empty list (no positions to align). LineageRepository.getLineage (line 1345): unconditional readValue on the cached JSON would throw and fail the request if Redis held a partial/corrupted/old-schema value — turning cache corruption into a persistent 500 until TTL expiry. Wrap the deserialize in try/catch; on failure log WARN with the root id and depth, invalidate the affected root's lineage hash, and fall through to a fresh computeLineage(). User sees the same answer as cache-off; subsequent requests repopulate. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): expireIfAbsent falls back to plain EXPIRE on NX failure The previous shape returned false silently when EXPIRE … NX wasn't supported (Redis < 7.0 syntax error, transient failure). That meant the preceding HSET-without-ttl call could leave the lineage hash key with no expiry at all, accumulating in Redis memory until the next manual invalidation. Catch the NX failure, log at DEBUG, and issue a plain EXPIRE so the key still gets a bounded lifetime. The trade-off: on older Redis, every variant write extends the expiry — strictly worse than the NX semantics on a 7.0+ deployment, but vastly better than the alternative of permanent unbounded keys. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(cache): copilot review pass 5 — dedicated mget conn + breaker + IT isolation + key collision Five comments from the latest copilot review on PR #28012: RedisCacheProvider.expireIfAbsent breaker bookkeeping (line 432, gitar-bot): the NX-fallback path issued a plain EXPIRE without recordSuccess() / recordFailure(), so a real network blip there was invisible to the sliding-window failure detector. Both success and failure now feed the breaker, consistent with every other Redis-calling method in the class. RedisCacheProvider.mget shared-connection hazard (line 692): even with pipelineLock, single-key callers using syncCommands/asyncCommands on the *same* connection had their commands buffered for the duration of the auto-flush-off window. Switched to a dedicated `pipelineConnection` / `pipelineAsyncCommands` created at init time and closed on shutdown. The shared connection's auto-flush is never toggled now, so unrelated request paths can't be starved by mget. pipelineLock still serializes mget vs mget on the dedicated connection. SystemResource.invalidateCacheForEntity fqn→id resolution (line 1113): the resolution call used `findByName(fqn, ALL, fromCache=true)`. That path consults NotFoundCache and the L1/L2 caches, which an admin force- invalidate is explicitly trying to recover from — a poisoned negative entry would short-circuit the resolution and silently skip every id-keyed cache layer. Switched to fromCache=false so the resolution always goes to the DB; only then can we trust the id we hand to CacheBundle / EntityRepository invalidation. CachedSearchLayerIT.java parallel-execution flakiness (line 50): the test assertions depend on deltas in the *global* /system/cache/stats counters. Under @Execution(CONCURRENT) other ITs issuing searches in parallel inflate the counters and the deltas either don't show up (false negative) or come from someone else's hits (false positive that masks broken cache keying). Marked @Isolated + ExecutionMode.SAME_THREAD so the class runs alone within its window. CachedSearchLayer.buildKey ambiguous encoding (line 220): fields were joined with a raw `|` delimiter, no escaping. A query string containing `|idx=foo` would produce the same preimage as a different (principal, index, query) tuple — cache-key collision → wrong cached response served to the wrong user. Added length-prefixed field encoding (`name=<utf8-bytes>:value|`); two distinct logical tuples can no longer serialize to the same hash input. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: Pere Miquel Brull <peremiquelbrull@gmail.com>
2026-05-13 13:41:09 +00:00
# Override that disables the cache while leaving the rest of the stack intact.
# Used in the local A/B benchmark to flip cache off without tearing down volumes.
# Apply on TOP of base compose (NOT the redis overlay):
# docker compose -f docker-compose.yml -f docker-compose.cache-off.yml up -d --no-deps openmetadata-server
services:
openmetadata-server:
environment:
CACHE_PROVIDER: none
Reference in a new issue Copy permalink