Skip to content

client_server_int_test - #7

Merged
orweis merged 7 commits into
masterfrom
client_server_int_test
Mar 9, 2021
Merged

client_server_int_test#7
orweis merged 7 commits into
masterfrom
client_server_int_test

Conversation

@orweis

@orweis orweis commented Mar 9, 2021

Copy link
Copy Markdown
Contributor

Test running full opal server and client for data updates

@orweis
orweis merged commit 6a9578c into master Mar 9, 2021
@asafc
asafc deleted the client_server_int_test branch March 14, 2021 07:25
roekatz pushed a commit that referenced this pull request Jun 9, 2023
Zivxx added a commit that referenced this pull request Jul 29, 2026
…phan-sweep safety/perf, zombie clamp, doc drift

Five HIGH / five MEDIUM / two LOW findings, all reproduced before fixing.

Lifecycle (HIGH #1, #2):
- The watcher's leader purge subscription now uses its OWN subscriber id.
  PubSubEndpoint files every server-side subscription under one shared id and
  EventNotifier.unsubscribe deletes that id's whole callback list for a topic,
  so unsubscribing by topic in stop() also dropped the every-worker
  handle_purge_message registered once at boot in server.py — leaving the
  process deaf to fleet purges for life, with nothing to re-add it.
- stop() now cancels its tasks BEFORE draining in-flight purges, and bounds the
  drain (_PURGE_DRAIN_TIMEOUT=5s). The old order awaited lock_source held by a
  sync across a whole clone/fetch — unbounded when SCOPES_GIT_FETCH_TIMEOUT is 0
  — whose release required the very cancellation the drain was blocking, while
  still holding the leadership lock. LeaderScopePurger gains signal_stop() and
  its "awaiting here cannot hang" docstring claim is gone (it was false).
- stop() is idempotent, and the comment claiming start()/stop() run exactly once
  is corrected: __aexit__ and stop_server_background_tasks both call it.

Orphan sweep (HIGH #3, MEDIUM #7):
- A SUCCESSFUL empty store read is no longer taken as "everything is an orphan".
  ScopeRepository.all() is a Redis SCAN loop that returns zero keys and no error
  against a wrong or empty keyspace, so a REDIS_URL on the wrong DB index, a
  failover to an empty replica or a stray FLUSHDB would rmtree every tenant's
  clone and broadcast confirmed purges fleet-wide. Refused (error-logged) unless
  the new OPAL_SCOPES_ORPHAN_SWEEP_RECLAIM_ON_EMPTY_STORE opts in; the git-leak
  bed sets it, since its FLUSHALL gate wants exactly that reclaim.
- The under-lock re-check now takes ONE fresh scopes.all() for the whole
  candidate batch instead of one per candidate (a full SCAN + a parse per record
  + two sha256 per live scope, each time): 2903ms -> ~10ms at 2000 all-orphan
  scopes, O(scopes + dirs) instead of O(orphans x scopes) Redis round trips.

Validation and docs (MEDIUM #10, #9, LOW #11, #12):
- SCOPES_GIT_MAX_ZOMBIES is clamped with max(0, ...). Unclamped, a negative
  value is truthy and `count >= cap` holds with nothing in flight, so the first
  git op was refused and no scope ever synced — while the one error line said
  "remotes appear stuck".
- Deleted the service.py prose still arguing that phase 2 must NOT inherit
  phase 1's cap, which the same commit reversed. NOTE: phase-2 concurrency did
  drop from a hard 32 to SCOPES_GIT_MAX_WORKERS (default 10) — the knob is now
  a true ceiling, but that default change was not advertised.
- Rewrote _periodic_orphan_sweep's docstring, which still described the sweep as
  living in _periodic_polling.
- Restored OPAL_SCOPES_GIT_FETCH_TIMEOUT's configuration.mdx text verbatim from
  config.py (drifted again after adade57 fixed it once).
- Documented the pop-before-publish invariant at both sites: publish() runs
  local subscribers inline, so handle_purge_message re-enters lock_source; the
  pop is what makes it mint a fresh lock instead of deadlocking.

Addresses review comments:
- #924 (comment) (@zeevmoney)
- #924 (comment) (@zeevmoney)
- #924 (comment) (@zeevmoney)
- #924 (comment) (@zeevmoney)
- #924 (comment) (@zeevmoney)
- #924 (comment) (@zeevmoney)
- #924 (comment) (@zeevmoney)
- #924 (comment) (@zeevmoney)
- #924 (comment) (@zeevmoney)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants