Add package embed — the ONE public surface for folding the Hanzo PubSub core
data plane (NATS + JetStream) into a host binary (hanzoai/cloud, HIP-0106),
mirroring iam/kms/tasks. Open() builds server.NewServer with JetStream on and
NoSigs (host owns signals), waits ReadyForConnections, and returns a handle with
ClientURL/NATS/Shutdown. Imports ONLY the self-contained, luxfi-free server
package — the same core the standalone pubsub deployment runs in prod
(--jetstream --store_dir, no consensus flags) — so a host compiles it cleanly
against its own dep set. Single-node JetStream over the file store: no
ZooKeeper/raft/etcd. The optional Quasar PQ + zapdb control plane stays in
package main (its internal/consensus adapter is pinned to the legacy
luxfi/consensus v1.22 API and is a follow-up to migrate before embedding).
Test proves a client round-trips core NATS and persists a JetStream publish.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
An online server that gets peer-removed could automatically be re-added
to the group, since it can still respond to the leader via heartbeats,
etc. if it didn't process the meta assignment update yet.
An online server that gets peer-removed could automatically be re-added
to the group, since it can still respond to the leader via heartbeats,
etc. if it didn't process the meta assignment update yet.
Commit
https://github.com/nats-io/nats-server/commit/f8656fe8ea5472e7be24435017e5c7b4a27a174a
removed the `info.fblk = info.lblk` which was done by default when
hitting `info.total == 1`. This is correct, since if you'd remove the
last message in the last block, you wouldn't be able to find the first
message in the first block.
In 2.14 this fix was included with
https://github.com/nats-io/nats-server/commit/08275d90cfb844a148571e913ff7d3fc62e16a9e,
which ensures both `fblk` and `lblk` are stored in the `index.db` file.
However, since this fix was not included since 2.12.7, this had a
side-effect that the stale `fblk` was always included in `index.db`,
without it being changed to reflect latest writes (which the previous
`info.fblk = info.lblk` was in essence hiding). That would result in not
being able to find certain messages if not being written to frequently,
after a server restart that recovers from this stale index. This PR
returns that check, but only does so if `MaxMsgsPerSubject: 1`, since
only then can we be sure to do that optimization.
Also fix a bug where an update from `MaxMsgsPerSubject: -1` to `1` was
not enforced during the update.
Commit
https://github.com/nats-io/nats-server/commit/7efb12612b779497153a897b443c65c1cdaffcb4
removed the `info.fblk = info.lblk` which was done by default when
hitting `info.total == 1`. This is correct, since if you'd remove the
last message in the last block, you wouldn't be able to find the first
message in the first block.
In 2.14 this fix was included with
https://github.com/nats-io/nats-server/commit/52fd51af6d756cbbc630a29ca0ce820b9e25113b,
which ensures both `fblk` and `lblk` are stored in the `index.db` file.
However, since this fix was not included since 2.12.7, this had a
side-effect that the stale `fblk` was always included in `index.db`,
without it being changed to reflect latest writes (which the previous
`info.fblk = info.lblk` was in essence hiding). That would result in not
being able to find certain messages if not being written to frequently,
after a server restart that recovers from this stale index. This PR
returns that check, but only does so if `MaxMsgsPerSubject: 1`, since
only then can we be sure to do that optimization.
Also fix a bug where an update from `MaxMsgsPerSubject: -1` to `1` was
not enforced during the update.
Fix two inconsistent scale down paths:
- A stream scale down would only select online peers, producing fewer
peers if some replicas were offline.
- A consumer scale down would only scale down to the "last N" peers
where N is the replica count to scale down to. This didn't take offline
servers into account, so could scale down such that there is no quorum
for the consumer to continue.
Both paths now: keep the current leader (if possible), prefer online
peers, fall back to offline peers.
Fix two inconsistent scale down paths:
- A stream scale down would only select online peers, producing fewer
peers if some replicas were offline.
- A consumer scale down would only scale down to the "last N" peers
where N is the replica count to scale down to. This didn't take offline
servers into account, so could scale down such that there is no quorum
for the consumer to continue.
Both paths now: keep the current leader (if possible), prefer online
peers, fall back to offline peers.
