Releases · hivellm/vectorizer

25 Apr 04:26

caikpigosso

v3.0.12

c4d07f0

v3.0.12 — fastembed as vectorizer-server default + lint fix

What changes

`fastembed` is now a real `[features] default` of `vectorizer-server` instead of a hard-coded entry on the `vectorizer = { features = [...] }` dep declaration. Behaviour is unchanged — `cargo build --bin vectorizer` still ships with FastEmbed enabled — but the dependency now follows normal feature plumbing. Slim builds without the ONNX runtime can opt out with `cargo build --no-default-features`.
Format fix under `cargo +nightly fmt` for the two `resolve_leader_addr` call sites in `raft_watcher.rs` (the calls were over the 100-col limit after the v3.0.9 signature change). The `Formatter and linter` workflow has been red since 3.0.9; this restores it to green.

Versioning

5 Rust crates + Rust SDK 3.0.11 → 3.0.12 (Cargo.lock refreshed); Helm chart `appVersion 3.0.11` → `3.0.12`, chart `version 1.5.8` → `1.5.9`. The HA fixes from 3.0.9 / 3.0.10 / 3.0.11 are unchanged.

🤖 Cut by Claude Code

Assets 10

25 Apr 03:29

caikpigosso

v3.0.11

6cf5976

v3.0.11 — Stop forced elections sabotaging stable Raft leaders

What changes

fix(raft): stop sabotaging stable elections with the AddNode retry loop.

Live test of v3.0.10 with verbose openraft logs proved the cluster was electing leaders cleanly (current_leader settles, AppendEntries flow), but the leader rotated every ~10 seconds. Pattern: vt3-1 → vt3-2 → vt3-1 …, always 10s after the previous transition.

Root cause: the post-bootstrap "register all nodes" task in `bootstrap.rs` ran on every pod, and its inner loop called `raft().trigger().elect()` unconditionally on every non-leader iteration. That forced a fresh election every 10 seconds on every follower, kicking the existing leader out before its first heartbeat could renew its lease.

Gate the trigger on `current_leader.is_none()` and a 30 s warm-up. If openraft already has a leader visible, followers just wait. The trigger only fires when openraft has genuinely stalled — the only situation the original comment was trying to handle.

Versioning

5 Rust crates + Rust SDK 3.0.10 → 3.0.11 (Cargo.lock refreshed); Helm chart `appVersion 3.0.10` → `3.0.11`, chart `version 1.5.7` → `1.5.8`. Server-side only fix.

🤖 Cut by Claude Code

Assets 10

25 Apr 02:56

caikpigosso

v3.0.10

320ca1b

v3.0.10 — Raft single-node bootstrap (no split-init)

What changes

fix(raft): only the lowest-ordinal node bootstraps Raft cluster.

Live test of v3.0.9 showed `current_leader` never settles — bootstrap log says "Raft cluster initialized successfully" on every node, but no election ever wins.

Root cause: `initialize_cluster` was called on every pod simultaneously. openraft's `initialize` writes to the local log/vote independently on each node — there is no cross-cluster atomicity until membership replicates via AppendEntries. With N pods racing through `initialize`, each one writes a divergent term-1 log entry naming itself as the initial voter. Subsequent Vote RPCs are rejected on log-mismatch grounds and the cluster never converges.

Fix: gate the `initialize_cluster` call on the lowest-ordinal server id (`-0` in a Kubernetes StatefulSet). Exactly one node bootstraps; the others wait, accept the membership log entry the bootstrap node propagates, and join cleanly.

Versioning

5 Rust crates + Rust SDK 3.0.9 → 3.0.10 (Cargo.lock refreshed); Helm chart `appVersion 3.0.9` → `3.0.10`, chart `version 1.5.6` → `1.5.7`.

🤖 Cut by Claude Code

Assets 10

25 Apr 02:28

caikpigosso

v3.0.9

21c18d5

v3.0.9 — Raft leader address resolution from membership

What changes

fix(raft): resolve leader address from openraft membership, not state machine.

Live test on a 3-node k3s cluster (v3.0.8) showed the Raft initial-election deadlock that has been blocking HA mode since v2.x. Vote RPCs now go through (the v3 transport fix landed correctly), but every follower then logs:

```
Leader address not found after retries
No leader address available, ReplicaNode not started
```

`resolve_leader_addr` was reading from `ClusterStateMachine.nodes`, populated only by post-bootstrap `AddNode` proposals — which never run reliably during initial election because the leader keeps rotating before the round-trip completes. Read from `openraft` membership config instead (set by `initialize_cluster()` and replicated as part of the Raft log within one round of `AppendEntries`); fall back to the state-machine map for dynamic AddNodes after bootstrap.

Versioning

5 Rust crates + Rust SDK 3.0.8 → 3.0.9 (Cargo.lock refreshed); Helm chart `appVersion 3.0.8` → `3.0.9`, chart `version 1.5.5` → `1.5.6`.

Status

`main` HEAD: `21c18d5e`. Server-side only fix; SDK / CI workflows unchanged from v3.0.8.

🤖 Cut by Claude Code

Assets 10

25 Apr 01:02

caikpigosso

v3.0.8

c148d88

v3.0.8 — drop musl from release matrix

Why a fresh tag

The aarch64 musl artifact has been the lone red through v3.0.5 → v3.0.7. Three independently-correct attempts at the OPENSSL_DIR leak (system override, empty-string passthrough, explicit `unset`) all failed because `cross` auto-forwards the leaked Win64 path into its container regardless of what Cross.toml passthrough says. Fixing it properly means either patching the cross-rs base image to clear the env itself, or replacing cross with a native `ubuntu-24.04-arm + musl-tools` build. Both are bigger than what belongs in a release.

v3.0.8 drops the musl job (kept as a commented block in the workflow with the failure analysis) and ships the rest of the matrix that already works.

What ships

`vectorizer-x86_64-unknown-linux-gnu` (amd64 Linux GNU)
Docker image `ghcr.io/hivellm/vectorizer:v3.0.8` (amd64 + arm64 multi-arch)
`vectorizer-aarch64-apple-darwin` (Apple Silicon)
`vectorizer-aarch64-apple-darwin-metal` (Apple Silicon with Metal GPU)
`vectorizer-x86_64-pc-windows-msvc` (Windows)
Helm chart `vectorizer-1.5.5` (`appVersion 3.0.8`)

Identical to v3.0.4 / v3.0.5 / v3.0.6 / v3.0.7 in code

Same replication-race fix, same empty-name guard, same SDK-shape alignment, same rust-tests CI server. v3.0.8 = v3.0.4 code + a clean release matrix.

What is not shipping

`vectorizer-aarch64-unknown-linux-musl`: dropped from the matrix until cross's auto-forward of OPENSSL_DIR is worked around. If you need a musl static binary today, `cargo build --release --target aarch64-unknown-linux-musl --features vendored-openssl` works locally as long as OPENSSL_DIR is genuinely unset in your shell.
`vectorizer-x86_64-apple-darwin`: dropped in v3.0.6 -- `ort-sys` has no Intel Mac prebuilt and the workflow has no `ORT_STRATEGY=compile` plumbing. Apple Silicon is the only macOS target now.

Versioning

5 Rust crates + Rust SDK 3.0.7 → 3.0.8 (Cargo.lock refreshed); Helm chart `appVersion 3.0.7` → `3.0.8`, chart `version 1.5.4` → `1.5.5`.

🤖 Cut by Claude Code

Assets 10

25 Apr 00:26

caikpigosso

v3.0.7

1cd5fa6

v3.0.7 — fix musl OpenSSL leak (unset, not empty)

Why a fresh tag

v3.0.6 cleared 8 of 9 release-artifact jobs (amd64 GNU + amd64 Docker + arm64 Docker on ubuntu-24.04-arm + Apple Silicon plain + Apple Silicon Metal + Windows + Linux dashboard + publish-docker). The musl job was the lone red, and the v3.0.6 attempt to fix it actually made it worse: setting `OPENSSL_DIR: ""` (and forwarding the empty value via Cross.toml passthrough) made openssl-sys treat the empty string as a user-supplied path and panic on `/include` before the vendored-openssl fallback could load.

v3.0.7 swaps `env:` for a real `unset OPENSSL_DIR OPENSSL_NO_VENDOR ...` inside the run script and drops both vars from Cross.toml passthrough so the container never sees them under any value. With both genuinely absent, openssl-sys skips the env check and the `vendored-openssl` feature builds a static OpenSSL bundled into the musl binary -- which was the intent all along.