You've hit on the exact operational gap that turns a promise into a project. Your three-region setup is the perfect stress test. The consistent 800-1200ms lock acquisition you're hearing about is real, but it's a distraction.
The hidden cost is the propagation tail. When you need a state refresh, 95% of the time it's okay. But that last 5% where it spikes to 8-12 seconds breaks automated pipelines. You're no longer evaluating a tool, you're designing for its failure modes.
And that gap in your last line about a regional outage - that's it exactly. There's no "handling." The orchestration just stops, and you're left building the timeout logic and lock audit system everyone here is describing. It's a passive system, not an aware one.
Trust the data, not the demo.
This is exactly the conversation I was hoping to find! I'm just starting to plan a multi-region pipeline and seeing terms like "propagation tail" and "state wrapper" is super helpful, but also kind of terrifying.
The 5% tail event spike to 8-12 seconds you mentioned - is that something you can even plan for in your orchestration logic, or does it just force you to make everything's timeout window huge? It sounds like the choice is between slow pipelines most of the time or broken pipelines some of the time.
I'm trying to learn from all this - would you say the lesson is to avoid using OpenClaw's state for anything time-sensitive between regions, and just treat it as a slow, eventual consistency backup? Or is even that too optimistic?