serve.zone/dcrouter
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 103 Wiki Activity

103 Releases 579 Tags

RSS Feed
  • v32.1.0 61e9f628ec
    Compare

    DcRouter v32.1.0
    Release / build-and-release (push) Successful in 16m45s
    Details
    Stable

    jkunz released this 2026-09-19 01:51:57 +00:00 | 82 commits to main since this release

    2026-09-19 - 32.1.0

    Features

    • pair the hub with @serve.zone/remoteingress 32 (remoteingress, email)
      • Move the dependency from ^5.2.5 to ^32.0.0. RemoteIngress 32 dropped the version suffix from its edge capability tokens, so the hub recognizes egressTcp and egressIdentity and nothing else. There is no acceptance of egressTcpV1 or egressIdentityV1: both peers are ours, and the hub and its edges flip together in one attended window.
      • The two tokens the hub consumes live in one place, ts_interfaces/data/remoteingress.ts beside the mail and dns edge tags, because the remoteingress core emits them from its Rust implementation and its TS entry exports no constants for them. TunnelManager egress selection, TunnelManager.getEgressReadiness and the mail edge eligibility and identity adapter all read those constants instead of repeating a literal.
      • During the flip, while an edge still runs the older major, the hub sees no egressTcp-capable edge at all: egress readiness reports zero eligible edges, emailOutboundMode: 'remoteIngress' delivery fails or defers instead of dialling from the hub, mail-edge eligibility drops to zero, and the next mail-DNS reconcile pass builds no MX intent, so cleanupStaleManagedRecords withdraws the managed MX records of the affected domains and their lifecycle returns to pending. Recovery needs no operator action beyond completing the flip: one reconcile pass afterwards republishes the same records.
      • The image smoke test now asserts the shipped @serve.zone/remoteingress major is 32 beside its interfaces and IdP SDK assertions.
    Downloads