Skip to main content
← Back to list
01Issue
BugIn ProgressSwamp CLI
Assigneesstack72

Relationships

#1610 --grant-reload auto does not detect filesystem changes — blind to ConfigMap updates

Opened by stack72 · 8/11/2026

Description

--grant-reload auto subscribes to in-process EventBus events (ModelCreated, ModelUpdated, DefinitionCreated, DefinitionUpdated) to trigger policy snapshot rebuilds. It does not watch the filesystem in any way — no Deno.watchFs, no polling, no inotify.

This means auto mode only reacts to grants created/modified through the API (e.g. swamp access grant create). If a grants YAML file is modified on disk — whether by a ConfigMap symlink swap, a direct edit, or a CI-driven deployment — the change is invisible to the server until an explicit swamp access reload is issued.

This is especially problematic for Kubernetes deployments where ConfigMap updates are the primary mechanism for policy changes. The Kubernetes kubelet swaps the ..data symlink atomically rather than writing files in place, so even if a filesystem watcher were added, it would need to watch the directory (not individual files) to detect the swap.

Steps to reproduce

  1. Start swamp serve with --grant-reload auto and a grants directory
  2. Modify a grants YAML file on disk (or update the ConfigMap in Kubernetes)
  3. Observe that the policy snapshot is NOT rebuilt — the old grants remain in effect
  4. Run swamp access reload --server wss://... — the new grants are now loaded

Expected behaviour

--grant-reload auto should detect filesystem changes to the grants directory and the --grants-file path. Options:

  1. Add Deno.watchFs on the grants directory (similar to WorkflowWatcher in src/libswamp/workflows/watcher.ts), watching the directory rather than individual files so ConfigMap symlink swaps are detected
  2. Add a polling fallback for environments where filesystem events are unreliable (network filesystems, some container runtimes)
  3. Document the limitation and recommend a sidecar/post-sync hook pattern for Kubernetes

Option 1 is strongly preferred — the WorkflowWatcher already demonstrates the pattern.

Environment

  • Reported by: Xero (enterprise, self-hosting on EKS)
  • Deployment: ConfigMap → grants directory, ArgoCD-managed
  • File: src/domain/access/policy_snapshot_loader.ts:121-153 (EventBus subscriptions)
  • Compare: src/libswamp/workflows/watcher.ts (existing filesystem watcher for workflows)
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 7 MOREREVIEW+ 1 MOREIMPLEMENTATION

In Progress

8/11/2026, 11:12:48 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/11/2026, 10:27:08 PM

Sign in to post a ripple.