feat(railiance): adopt state-hub edge relay beachhead for WP-0015
Deploy actcore-statehub-edge-relay, point STATE_HUB_URL at it, retire the bespoke state-hub bridge, and accept edge-relay queued write receipts in report and ops evidence sinks.
This commit is contained in:
parent
1a0636845a
commit
cdbe4de2bf
13 changed files with 256 additions and 136 deletions
|
|
@ -445,12 +445,15 @@ events once State Hub / the beachhead honours the header.
|
|||
The guarantee lives on the write, not on a live dedup read. The read-based
|
||||
`_progress_exists` check is now best-effort only: if State Hub is unreachable it
|
||||
returns `False` (proceed to the keyed write) rather than hard-failing. The header
|
||||
passes untouched through the `actcore-state-hub-bridge` proxy and is ignored by
|
||||
State Hub versions that do not yet honour it.
|
||||
is honoured by the in-cluster `actcore-statehub-edge-relay` (state-hub edge
|
||||
relay) and central State Hub on replay. Allowlisted `GET` reads are cached by the
|
||||
relay and served stale (`X-StateHub-Edge-Cache: stale`) when upstream is briefly
|
||||
unreachable, which keeps daily triage context resolution alive during outages.
|
||||
|
||||
> The queue/cache itself is **not** built in activity-core — it belongs to the
|
||||
> state-hub beachhead. activity-core only emits the key. See the proposal sent to
|
||||
> the `state-hub` agent.
|
||||
> state-hub edge relay. activity-core emits the key, treats HTTP 202 queued
|
||||
> receipts as successful sink delivery pending replay, and consumes stale cached
|
||||
> reads transparently.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue