From 7876758c1224254eff667ccae9f765dabb622a85 Mon Sep 17 00:00:00 2001 From: mvdbeek Date: Mon, 13 Jul 2026 15:26:21 +0200 Subject: [PATCH] source store: stop calling the cvmfs revision a consistency proof The boot path trusts read-only stores by construction; the stamped revision could never match (populated at revision N inside the publish transaction, clients see N+1). The probe only feeds the watcher's change detection, so say that. --- lib/galaxy/tools/source_store/freshness.py | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/lib/galaxy/tools/source_store/freshness.py b/lib/galaxy/tools/source_store/freshness.py index 2e78a563500..d80b6a0d886 100644 --- a/lib/galaxy/tools/source_store/freshness.py +++ b/lib/galaxy/tools/source_store/freshness.py @@ -19,9 +19,14 @@ Two probe kinds exist: automatically. - ``cvmfs``: the CernVM-FS repository revision, read from the ``user.revision`` extended attribute the CVMFS client exposes on the - mount point. One syscall covers every file in the repository. For a - store whose sqlite bundle is published in the same CVMFS transaction as - the tools it indexes, a matching revision is a hard consistency proof. + mount point. One syscall covers every file in the repository. This + probe only feeds the watcher's change detection: a revision transition + means a new publish landed and cached state should reload. It is *not* + a boot-time token comparison — read-only stores are trusted as + published (see ``SqlAlchemyToolSourceStore.index_is_fresh``: the bundle + ships in the same transaction as the tools it indexes), and a stamped + revision could never match anyway, since the publisher populates inside + the transaction at revision N while clients see N+1. """ import hashlib