---
title: "Lease Ownership Fix Pressure-Test"
canonical: "https://mumo.chat/p/lease-ownership-fix-pressure-test-jecygl"
machine_version: 1
models: ["GPT","Grok","Muse"]
round_count: 3
published_at: "2026-07-11T17:07:23.156109+00:00"
updated_at: "2026-07-11T17:13:07.674+00:00"
brief_source: "session_takeaway"
full: "https://mumo.chat/p/lease-ownership-fix-pressure-test-jecygl.md"
---

> Brief of a mumo multi-model deliberation — the session synthesis
> without the transcript. This is an orientation surface; to audit the
> synthesis against the models' actual prose, read the full transcript.
> Full deliberation with evidence: https://mumo.chat/p/lease-ownership-fix-pressure-test-jecygl.md

# Lease Ownership Fix Pressure-Test

*A multi-model AI conversation on mumo*
*July 11, 2026*

**Panel:** GPT · Muse · Grok · 3 rounds

---

## Question

Pressure-test a proposed fix to a lease-ownership bug in our distributed lock service. This is a CORE mechanic (every stateful worker takes locks through it), so I want adversarial scrutiny of correctness — not validation.

## System background

Workers acquire named leases via `POST /v1/leases` with `{name, owner_id, ttl_ms}`. Storage:

`leases(name PK, owner_id, expires_at, fencing_token)`

Fencing tokens come from a monotonic allocator **`lease_token_seq`** (Postgres sequence), not from the deleted row. Acquire roughly:

1. allocate `next_token = nextval('lease_token_seq')` (or allocate only on successful take)
2. reclaim/update expired row or insert: compare-and-set on `expires_at < now()` / missing name
3. return token to client

Renew is `PATCH` with token; release is `DELETE`/`UPDATE` with token. Clients are documented to present fencing tokens on data-plane writes; compliance varies by worker class.

## The bug (prod)

During Tuesday’s regional blip, worker `indexer-17` held `shard:8841` with token 402. Process froze (GC thrash) past TTL. `indexer-04` acquired token 403 and wrote. `indexer-17` unfroze, still believed it held 402, and wrote to the shard’s Kafka output for… *(prompt truncated — full text in the full transcript)*

## Session Takeaway

*(mumo-generated synthesis of the whole session — evidence lives in the full transcript)*

**Ship consumer-side high-water fencing Friday by treating the Kafka log as untrusted, but accept permanent operational debt and a mandatory migration to broker-native epochs once the topology expands.**

The moderator opened by demanding adversarial scrutiny of a lease-ownership fix, steering the panel away from validating the proposed Redis revocation stream and toward identifying where safety actually lives. The discussion pivoted from general failure modes to a specific choice between broker-native fencing and consumer-side high-water marks. It closed with a conditional go for Friday, contingent on strict topology controls and a redefinition of the Kafka log as untrusted ingress.

### Arcs

#### HELD — Revocation streams are UX latency optimizations, not safety mechanisms. (Rounds 1, 2, 3)

The panel unanimously rejected the idea that a Redis stream could prevent split-brain writes, noting that a GC-frozen process cannot process revocation messages. This position held from the first round through the final verdict, forcing the design to rely on enforcement at the point of data acceptance rather than notification.

#### SHIFTED — Broker-native fencing is the architectural ideal, but consumer-side high-water marks ship Friday. (Rounds 2, 3)

The session started with strong advocacy for broker-native fencing via transactional IDs, but shifted to consumer-side high-water marks after recognizing the Thursday validation risks and coordinator bottlenecks. This shift required redefining the raw Kafka topic as an untrusted ingress log, accepting that stale records will remain visible as long as the materializer enforces the fence.

#### UNRESOLVED — High-water fencing creates permanent operational debt by leaving the Kafka log dirty. (Round 3)

While the panel agreed to ship the consumer-side fix, they preserved dissent that this approach leaves the underlying log vulnerable to misinterpretation by future consumers or operational tools. The unresolved tension is that any new consumer group appearing next quarter will break the safety model, forcing a costly migration back to broker-native epochs.

---

## Round Map

- **Round 1:** The current proposal is a no-go for Friday because it relies on best-effort Redis revocation for safety and incomplete middleware fencing, leaving the original split-brain vulnerability wide open.
- **Round 2:** Prioritize broker-native fencing as the primary safety goal, but be ready to fall back to sink-side high-water mark enforcement if rigorous testing fails by Thursday.
- **Round 3:** We can ship this safely on Friday by enforcing fence-checking at the consumer level, but it creates permanent operational debt by leaving the underlying Kafka log 'dirty.'

---

**Full deliberation with evidence:** https://mumo.chat/p/lease-ownership-fix-pressure-test-jecygl.md