uploadChunk only wrapped withBatchRecovery (402), so a Bee 429 —
returned when concurrent uploads hit the same postage batch (multiple
api replicas + worker) — failed the whole completion instead of backing
off. Wrap the upload in withRateLimitRetry so a transient throttle
becomes a slightly slower success.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TYhvtQe5q6SLAmcCaUk9HD
Bee 2.8's pushsync from homelab to prod consistently routes our trojan
chunks to neighbour ff7adaed instead of prod_bee at ff896a93, even with
both nodes directly peered. The chunk lands at a third-party node that
can't decrypt it, so the gateway never receives provider ack/deliver
envelopes and the chat times out.
Workaround: gateway advertises a clientReplyUrl in job_notify. Provider
POSTs the same signed envelopes there; gateway verifies the signature
(same trust check as the PSS subscription) and dispatches via the same
onEnvelope handler. PSS remains the fallback when no replyUrl is set
(non-hosted clients).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Bee closes the pssSubscribe WebSocket after ~8s of idleness (or on any
transient hiccup). The previous handler only logged the close — so the
gateway silently went deaf to every ack/deliver envelope that arrived
after the first close, breaking every chat whose provider takes more
than a few seconds to respond. Re-open the subscription on close with a
short delay; cancel() now blocks further reopens.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
