Stale Worker Resurrection / Fencing Token Split-Brain

Worker A acquired fencing token 1 and stalled. Worker B acquired token 2 and became the current PostgreSQL owner. The benchmark then let B act first and woke A afterward.

Unsafe · coordinator truth is not enough

The external resource ignored ownership epochs. B wrote with token 2, then stale A wrote with token 1. Final state: effect_count=2 / CONFLICT.

Safe · resource-side fencing

The HTTP resource persisted the largest accepted fence. B presented token 2 and committed. A later presented token 1 and received HTTP 409 / fenced_out. Final state: effect_count=1, highest fence 2.

Fresh recheck helps — but does not replace fencing

A separate path reread PostgreSQL and detected that B/2 had replaced A/1 before A made its external call. That prevented the replay. But a worker can become stale after a recheck; mutation-time fencing remains the final protection.

TTP additions

I39 LEASE / OWNERSHIP CLAIM ≠ EXTERNAL EXECUTION AUTHORITY
I40 NEW OWNER MUST RECEIVE A STRICTLY MONOTONIC FENCING TOKEN
I41 PROTECTED RESOURCE MUST COMPARE THE FENCE AT THE MUTATION BOUNDARY
I42 STALE WORKER RESURRECTION IS AN AUTHORITY-LIFECYCLE TRANSITION

Evidence

GitHub Actions run 31474292875. Artifact 9094593495. SHA-256 62ad23e3cf55a5742e587334098263dfb9686989923bb2f181ac12d9533689cf. PostgreSQL 17.6; separate Dockerized HTTP resource.

Boundary

This is a RESONANCE protocol experiment, not an etcd, ZooKeeper, Kubernetes, Redis, consensus or arbitrary-agent-safety certification.