Safety Policies

Swytch 1.6+ lets you set a default transaction safety policy and override it for individual keys or key patterns using Redis CONFIG.

Safe mode checks that subscribed peers are available before attempting a transaction. Unsafe mode skips that preflight check, allowing transactions to proceed when peers are unavailable. Both modes use the same transaction coordination, ACK/NACK handling, and conflict arbitration. A partition occurring after preflight can still produce competing histories. See designing for partitions and transaction conflict reports.

CONFIG SET cluster_safe_mode safe
CONFIG SET key_safe_mode '{"sessions::*":"unsafe","sessions::critical":"safe"}'
CONFIG GET cluster_safe_mode
CONFIG GET key_safe_mode

cluster_safe_mode defaults to safe. It applies to application keys without an override. Both settings accept only lowercase safe and unsafe values.

key_safe_mode is a JSON object mapping exact keys or Redis glob patterns to policies. Each CONFIG SET key_safe_mode replaces the entire override map. To remove all overrides:

CONFIG SET key_safe_mode '{}'

Patterns support Redis glob syntax, including *, ?, character classes ([ab], [a-z]), negated classes ([^a]), and backslash escapes. Escape backslashes again when writing them inside JSON strings.

When more than one pattern matches, Swytch chooses the policy in this order:

1. Exact keys before wildcard patterns.
2. Longer literal prefixes before shorter ones.
3. Lexical order to break ties.

For example, sessions::* can be set to unsafe while sessions::critical remains safe. With sessions::* set to safe and sessions::public* set to unsafe, sessions::public123 uses unsafe while sessions::private uses safe.

Internal __swytch:* keys always use the engine’s unsafe policy, including the policy configuration keys, so they remain writable during a partition.

The CONFIG settings use ordinary Swytch keys:

You can also manage them directly:

SET __swytch::dc unsafe
HSET __swytch::kc 'sessions::*' safe
HGETALL __swytch::kc
HDEL __swytch::kc 'sessions::*'
DEL __swytch::kc
DEL __swytch::dc

Unlike CONFIG SET key_safe_mode, HSET changes one override without replacing the others. Deleting __swytch::kc clears all overrides; deleting __swytch::dc restores the safe default. Normal key ACLs apply to direct access.

After membership bootstrap, Swytch subscribes to both configuration keys, even when they don’t exist yet. Beacon and standalone runtimes watch for changes and apply the reconstructed policy locally. Applications don’t need to subscribe to these keys themselves.

Changes propagate through ordinary Swytch subscriptions and are applied asynchronously. CONFIG GET reads the locally reconstructed stored configuration; it does not confirm that every node has applied the new policy. During a partition, nodes may temporarily use different policies until they receive the updated history.

These keys follow the normal storage lifecycle. There is no separate policy configuration file.

CONFIG SET validates values before writing them, but direct writes can store an invalid value or type. If either backing key is invalid, Swytch logs a warning and uses the defaults: safe for application keys, with no overrides. It resets the entire active policy, not just the invalid entry. Internal keys keep their unsafe exception.

This fallback applies during live updates, startup recovery, and peer joins. Invalid stored values do not prevent startup or stop the configuration watcher. Fix the backing keys with direct commands or CONFIG SET; the corrected policy then propagates normally.

The fallback does not rewrite stored keys, so CONFIG GET may still return a validation error while the engine is running with default policies.