Proto commits in streamnative/oxia

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-07-06

fix: preserve metadata YAML numeric types (#1207) ## Motivation Cluster metadata stored in Kubernetes ConfigMaps is part of the upgrade/downgrade compatibility surface. The previous protobuf JSON-to-YAML write path emitted `map<int64, ...>` keys and `int64` values as YAML strings, which differs from the 0.16.x metadata format and can make rollback compatibility fragile. This change keeps metadata writes in the numeric YAML shape expected by older releases while preserving the existing protobuf-aware read path with unknown-field tolerance. Round-trip tests cover the known config/status fields we write, so the read path can keep tolerating future unknown fields without silently dropping current metadata fields. ## Modifications - Write cluster config and status YAML directly from typed protobuf structs with `yaml.v3`. - Add generated YAML tags for metadata protobuf fields and wire `protoc-go-inject-tag` into `make proto`. - Preserve the existing YAML read path through `YAMLToJSON -> protojson.Unmarshal` with `DiscardUnknown` enabled. - Keep unset optional/repeated/map/default YAML fields omitted, avoiding `null`, empty collection, and zero-value output for unset metadata fields. - Strengthen codec tests for lowerCamel config output, full known-field config round-trip, numeric status shard keys, numeric `int64` values, omitted unset fields, zero top-level status fields, and YAML unknown-field compatibility. - Replace the numeric shard-key test assertion with a whitespace-tolerant regex so it does not depend on exact YAML indentation. ## Testing - `go test ./oxiad/coordinator/metadata/common/codec -count=1` - `go test ./oxiad/coordinator/metadata/common/codec ./oxiad/coordinator/metadata -count=1` - `go test ./oxiad/coordinator/metadata/common/codec ./oxiad/common/rpc ./oxiad/dataserver ./oxiad/coordinator/metadata ./oxiad/coordinator/rpc ./oxiad/coordinator/runtime ./oxiad/maelstrom -count=1` - `git diff --check` - Built and loaded a local image into a local kind cluster. - Upgraded `oxia-compat` from `0.16.7` to the local image far enough to verify the rewritten status ConfigMap kept numeric shard keys and `int64` values; full rollout is still blocked by the separate instance-id compatibility issue. - Downgraded/restored `oxia-compat` to `0.16.7`; all pods were ready and client read/write succeeded. Signed-off-by: mattisonchao <mattisonchao@gmail.com>

The documentation is generated from this commit.

2026-07-01

test: add end-to-end auto-split test (+ configurable collection interval) (#1206) ## Summary Adds the end-to-end validation for auto-split (design Phase 5) plus the small config knob it needs. 1. **Configurable collection interval** — a new `collection_interval` field on `AutoSplitConfig` lets the monitor's poll cadence be tuned per cluster (default `30s`, following the existing `LoadBalancer` duration pattern). The runtime derives the monitor interval from cluster config, and `ClusterConfiguration.Validate()` rejects a malformed value. This also resolves the earlier review note about the hard-coded interval. 2. **End-to-end auto-split test** (`tests/coordinator/auto_split_e2e_test.go`) — brings up a 3-node cluster with auto-split enabled (1 MiB size threshold, `200ms` poll interval, `max_shards_per_namespace: 2`), writes ~4 MiB of incompressible data, and asserts the coordinator splits the oversized shard **on its own** (no manual `InitiateSplit`). It then verifies the resulting shards tile the full hash range `[0, MaxUint32]` contiguously and that every written key is still readable through a fresh client. The 2-shard cap makes the outcome deterministic — the oversized shard splits exactly once, and the guard-rail then prevents the (still-large) children from cascading — while also exercising the `max_shards_per_namespace` guard-rail end to end. ## Test plan - [x] `TestCoordinator_AutoSplit` passes, including with `-race`, and is stable across repeated runs (~16-18s each). - [x] Existing `TestCoordinator_ShardSplit` (manual split) still passes — no regression. - [x] Unit tests for the new `collection_interval` helper + validation; full `common/proto` and `autosplit` suites pass with `-race`. - [x] `gofmt`, `go vet`, `golangci-lint` clean on changed files. - [x] Proto regenerated with protoc 34.1 (matching CI); only the `metadata` generated files change. --------- Signed-off-by: Matteo Merli <mmerli@apache.org>

feat: expose namespace admin status view (#1203) ## Motivation Namespace reads currently return only the configured namespace object, so operators cannot see runtime namespace status such as the current shard set from the admin API or CLI. This adds a namespace view that mirrors the dataserver view pattern introduced by PR #1129. ## Modifications - Add `NamespaceView` to the admin proto and return it from namespace get/list responses. - Populate namespace views from coordinator metadata status. - Update the admin client and namespace CLI get/list output to expose namespace status. - Add unit and e2e coverage for namespace status output. ## Testing - `go test ./cmd/admin/... ./oxia ./oxiad/coordinator` - `go test ./tests/coordinator -run TestAdminNamespaceCreateAndGet -count=1` - `make lint` --------- Signed-off-by: mattisonchao <mattisonchao@gmail.com>

feat: expose shard admin status view Signed-off-by: mattisonchao <mattisonchao@gmail.com>

refactor: expose only namespace runtime status Signed-off-by: mattisonchao <mattisonchao@gmail.com>

feat: expose namespace admin status view Signed-off-by: mattisonchao <mattisonchao@gmail.com>

feat: expose dataserver admin status view (#1129) ## Motivation - Admin `GetDataServer` and `ListDataServers` currently return only the configured `DataServer` object. - Management clients need a read model that can include runtime status without polluting mutable dataserver config. ## Modifications - Add `DataServerState` and `DataServerStatus` to `metadata.proto`. - Add admin `DataServerView { data_server, data_server_status }` and return it from dataserver read APIs. - Keep create, patch, and delete operations using the existing `DataServer` config object. - Assemble dataserver status from runtime controller state and supported features. - Update admin client, CLI get output, and tests for the read-view shape. ## Testing - `go test ./common/proto` - `go test ./oxia ./cmd/admin/dataserver/... ./common/proto` - `go test ./oxiad/coordinator/...` - `go test ./tests/coordinator` - `go test ./oxiad/...` --------- Signed-off-by: mattisonchao <mattisonchao@gmail.com>

2026-06-30

fix: simplify dataserver status view Signed-off-by: mattisonchao <mattisonchao@gmail.com>

feat: expose dataserver admin status view Signed-off-by: mattisonchao <mattisonchao@gmail.com>

feat: add ShardStats to GetStatus and auto-split config protos (#1202) ## Summary - Add `ShardStats` message (`db_size_bytes`, `read_ops_total`, `write_ops_total`) to `GetStatusResponse` in `replication.proto`, enabling the coordinator to collect per-shard metrics from leaders without a new RPC surface - Add `ShardManagement` / `AutoSplitConfig` messages to `metadata.proto` with configurable thresholds, stabilization/cooldown periods, and a `max_shards_per_namespace` guard-rail - Populate `ShardStats` in the leader controller's `GetStatus` handler using atomic counters in the DB layer and Pebble's `DiskSpaceUsage()` - Add `DiskSpaceUsage()` to the `KV` interface for programmatic access This is the data-collection and configuration foundation for automatic shard splitting (Phase 1 & 2). The auto-split monitor that consumes these stats will follow in a subsequent PR. ## Test plan - [x] Existing `TestLeaderController_GetStatus` extended to verify `ShardStats` is populated with correct values after write operations - [ ] `make test` passes - [ ] `make lint` passes - [ ] `make proto` is a no-op (generated code is up to date) --------- Signed-off-by: Matteo Merli <mmerli@apache.org>

2026-06-29

feat: configure coordinator public addresses from cluster config (#1201) ## Motivation Kubernetes deployments need coordinator public addresses to be configured at the cluster level because the address clients should use is often not the same address visible from inside the coordinator pod. Operators may need to advertise a LoadBalancer hostname, DNS name, or another externally reachable endpoint, and chart wiring should not require separate per-coordinator ConfigMaps just to carry that public identity. The public address is part of cluster topology: it describes how users and other components should reach a named coordinator, independent of whichever pod currently owns a lease or what that pod sees as its local bind address. Keeping this mapping in cluster configuration gives every coordinator a single shared source of truth, lets the Kubernetes lease store only the stable coordinator name, and avoids duplicating externally visible routing data inside each coordinator process config. ## Modifications - Public configuration changed: add `clusterConfig.coordinators[]` entries with `name` and `publicAddress`, add coordinator-local `metadata.name`, and remove coordinator-local `server.public.advertisedAddress`. - Add `Coordinator` entries to `ClusterConfiguration` and lookup/validation helpers. - Simplify the Kubernetes metadata provider lease identity to the coordinator name. - Regenerate metadata protobufs and coordinator config schema. ## Testing - `go test ./common/proto ./oxiad/coordinator/option ./oxiad/coordinator/metadata ./oxiad/coordinator/metadata/provider/... ./cmd/coordinator` - `go test ./cmd/... ./common/... ./oxiad/coordinator/...` --------- Signed-off-by: mattisonchao <mattisonchao@gmail.com>

2026-06-28

feat: configure coordinator public addresses from cluster config Signed-off-by: mattisonchao <mattisonchao@gmail.com>

2026-06-27

feat: configure coordinator public addresses from cluster config

2026-06-26

fix: drain split children before fencing the parent at cutover (#1197) ## Problem Under concurrent write load, shard-split **cutover can hang or lose acknowledged writes**. `runCutover` fenced the parent shard first. Fencing (`NewTerm`) destroys the parent's observer cursors — the mechanism that streams data to the child shards — so the children can never receive the tail of entries written between the last CatchUp snapshot and the fence. The split then hangs in cutover until it times out. Every existing split test splits a **quiescent** parent (writes stop before the split begins), so this gap was never exercised in CI. ## Fix: freeze-then-fence Add a `FreezeShard` RPC and rework cutover to **freeze the parent → drain the tail to the children → fence**: - A *frozen* leader rejects new write proposals in `leaderController.propose` with a retryable `ErrNodeIsNotLeader` (clients re-resolve and route to the children once cutover completes). Its head stops advancing, but it is **not** fenced, so its observer/follower cursors keep streaming. `frozen` is an `atomic.Bool`, cleared on every `NewTerm` so a re-elected/fenced leader never inherits a stale freeze. - Cutover waits on the child **head** offset, not commit. A child runs as an observer-follower whose commit is capped at the parent's *advertised* commit offset; once the parent is frozen, no new entry carries an updated commit, so the child's commit would stall one entry below the frozen head forever. The child holds the entries in its WAL (head); re-electing it in a clean term commits them through the child's own quorum. (This matches the original design, which targeted the parent's head.) - A timed-out cutover is aborted (and the parent unfrozen) only **before** the fence; after the fence it is forward-only and resumed from the persisted split phase. ## Testing - New `TestCoordinator_ShardSplit_WritesDuringSplit`: writes continuously through the entire split and verifies every acknowledged write survives on the children. Hangs on the old fence-first cutover; ~366 keys are acknowledged during cutover in local runs. - New `TestLeaderController_Freeze`: writes rejected while frozen, reads still served, head returned, freeze cleared on new term. - Full `tests/coordinator` split suite, the split-controller unit suite, and dataserver lead/follow controller tests pass; `golangci-lint` clean against the CI-pinned v2.6.2. --------- Signed-off-by: Matteo Merli <mmerli@apache.org>

2026-06-15

feat: encode coordinator info in metadata lease (#1156) ## Motivation - Coordinator management API redirects need the elected coordinator's public management address. - Kubernetes leader election currently stores only an opaque identity string in the lease holder. ## Modifications - Add `server.public.advertisedAddress` and default it from the public bind address when unset. - Add metadata protobuf `CoordinatorInfo` with coordinator identity and public address. - Encode `CoordinatorInfo` into Kubernetes lease holder identity and provide decode support for future redirect logic. - Wire configmap metadata providers to use coordinator identity plus advertised public address. - Add tests for advertised address defaulting and coordinator lease info encoding. ## Testing - `jq empty conf/schema/coordinator.json` - `go test ./common/proto ./cmd/coordinator ./oxiad/coordinator/... ./tests/coordinator` --------- Signed-off-by: mattisonchao <mattisonchao@gmail.com>

2026-06-13

perf: make the notification batch marshal deterministic by construction (#1190) ### Motivation Item 2.4 from the performance review: notifications were the last reflection-based marshal on the write path — `pb.MarshalOptions{Deterministic: true}.Marshal(...)` once per `ProcessWrite`, paying reflection plus per-call map sorting. Determinism is a correctness requirement here, not hygiene: the serialized batch feeds the replicated batch checksum, so every replica must produce identical bytes for the same logical content. ### Changes **`NotificationBatch.notifications` becomes `repeated NotificationEntry`** (was `map<string, Notification>`). A protobuf map entry encodes exactly as `NotificationEntry{key = 1, value = 2}`, so the change is wire-compatible in every direction: old persisted batches decode into the repeated field, new batches decode into old readers' maps, and old/new client–server combinations interoperate. With a repeated field, determinism becomes **structural** — generated marshalers emit slice order — instead of requiring a special marshaler (reflection-based or hand-written). - The write-side `Notifications` wrapper appends entries as operations are recorded; `seal()` stable-sorts in place and drops superseded duplicates in one linear pass (last operation on a key wins, as the map gave us — the sort must be stable so "last within a run of equal keys" still means "last applied"). The batch then implements `ProtoMarshalable` and lands directly in the Pebble batch arena (#1189). - The split-filter rewrite path drops its reflection marshal too: filtering preserves the stored (sorted) order, so its rewrite is deterministic by construction. - `NotificationEntry.key` is proto3 `optional`: presence-tracked, so an empty key is emitted exactly as a map entry encodes it. - API note: `NotificationBatch` is in `client.proto`, so other-language clients get a generated-API change (slice instead of map) on regeneration; wire-level they are unaffected. Design alternatives measured along the way: a side dedup map (rejected — 25–33% slower on duplicate-free batches, the common case; wins only on dup-heavy ones) and a hand-copied sorted vtproto emission plus a wire-compatible twin message (both superseded by making the canonical message repeated). `vtprotobuf`'s generator has an unexposed `Stable` flag with exactly the sorted-map emission; exposing it upstream would have been the other path. ### Compatibility Golden byte vectors captured from the previous map-based code pin the cross-version contract: replicas still running the old code must keep agreeing on the checksum. `TestNotificationBatchGoldenBytes` asserts the new bytes equal the old marshaler's output across empty/scalar-only/single/mixed-types/30-key cases (including an empty key), with 20× repeat stability and an `UnmarshalVT` round-trip. With the sort removed, it fails 42 assertions. `TestNotificationsSealDeduplicates` pins last-wins (put-then-delete: the delete survives) and fails against a keep-first variant. ### Benchmark Seal + marshal of a 10-notification batch (Apple M1 Max): | version | time | allocs | |---|---|---| | reflection `Deterministic` on the map (before) | 2497 ns | 25 | | repeated field, generated marshal (after) | **314 ns** | **1** | ### Verification - `go test -race` green on `oxiad/dataserver/{database,database/kvstore,controller/lead}`, the `oxia` client module, and `tests/client` e2e (notifications suite). - `golangci-lint` clean on the CI-pinned v2.6.2 across `common`, `oxiad`, and `oxia`. --------- Signed-off-by: Matteo Merli <mmerli@apache.org>

2026-06-11

fix: coalesce follower acks into one cumulative ack per sync round (#1164) ### Motivation After each fsync round, the follower acknowledges every entry individually: one sync covering hundreds of entries produces hundreds of `Ack` messages, each paying a proto allocation and an HTTP/2 frame on the follower, and a stream receive plus one quorum-ack-tracker lock acquisition on the leader. At 100k entries/s with RF=3 that is ~200k unnecessary messages per second in each direction's processing, and it multiplies the acquisition rate of the tracker mutex. Acks are inherently cumulative: the follower appends and syncs strictly in order, so confirming offset N implies everything below it. ### Changes - **Leader: cumulative ack accounting.** `cursorAcker.Ack(offset)` now confirms the whole range `(lastAcked, offset]` under a single tracker-lock acquisition (clamped to the commit offset, so ranges never walk already-committed entries). This matches the semantics the tracker already used for attach-time acks in `NewCursorAcker`, and it is compatible with older followers: their dense, in-order, per-entry acks are degenerate ranges of size one. - **Follower: coalesced acks, negotiated.** `bgSyncer` sends a single `Ack{Offset: newHead}` per sync round — but only when the leader advertises support through the new `cumulative_acks_supported` field on `Append`. Otherwise it keeps the per-entry loop. ### Rolling-upgrade compatibility The negotiation is what makes this safe to ship in one release. The hazardous combination is an upgraded follower talking to an old leader: a coalesced ack would be accounted as a single offset, the skipped offsets would never reach quorum from that follower, and with enough upgraded followers the shard's commit offset would stall until the leader restarts. With the `Append` flag, that combination keeps per-entry acks; new-leader/old-follower works because cumulative accounting subsumes per-entry acks. Both mixed states commit correctly. ### Verification - New `TestQuorumAckTracker_CumulativeAck` (single cursor: range commit, stale/duplicate acks as no-ops) and `TestQuorumAckTracker_CumulativeAckQuorum` (RF=5: commit only advances to what a quorum confirmed — first cursor acking 5 commits nothing, second acking 3 commits exactly 3). - New `TestFollower_CumulativeAcks`: end-to-end through the mock replicate stream with the flag set — ack offsets strictly increasing, final entry confirmed, never more acks than entries. - All existing tracker/follower/cursor tests pass unchanged; `go test -race` green on the whole `oxiad` module, the `oxia` client module and the full `tests/` integration suite (which exercises the negotiated cumulative path end-to-end through real replication). - `golangci-lint`: no new findings (the one reported gosec issue pre-exists on unmodified `main`). - Proto regen limited to `replication.*`; sibling generated files only had protoc-version comment churn and were reverted. Noticed while in this code, pre-existing and not addressed here: the duplicate-entry ack in `append0` sends on the Replicate stream from the appender goroutine while `bgSyncer` sends from its own — concurrent `SendMsg` on one stream is documented unsafe in grpc-go. Tracked separately. Related: #1158–#1162 (write-path series from the same performance review); this directly reduces the acquisition rate of the tracker mutex from #1159. --------- Signed-off-by: Matteo Merli <mmerli@apache.org>

2026-06-02

chore: update copyright notices for 2026 (#1151) ## Motivation - Keep repository copyright notices current and consistent for 2026. - Align top-level notices, generated files, and source headers that still referenced 2025. ## Modifications - Updated `Copyright 2023-2025 The Oxia Authors` to `Copyright 2023-2026 The Oxia Authors` across the repository. - Left the Apache-2.0 license terms unchanged. ## Testing - `git diff --check` - `make license-check` Signed-off-by: mattisonchao <mattisonchao@gmail.com>

2026-05-18

fix: simplify dataserver status view Signed-off-by: mattisonchao <mattisonchao@gmail.com>

2026-05-14

feat: expose dataserver admin status view Signed-off-by: mattisonchao <mattisonchao@gmail.com>

2026-05-13

fix: standardize Oxia gRPC error handling (#1119) ## Motivation - Carry Oxia-specific error reasons and leader hints through standard gRPC `ErrorInfo` details. - Translate server gRPC errors back into Oxia sentinel errors at the client/provider boundary. - Keep retry and leader-hint handling in the RPC provider instead of scattering it across batch logic. ## Modifications - Add common Oxia error reasons, sentinel errors, metadata helpers, and gRPC conversion helpers. - Convert public and internal RPC handlers to return enriched gRPC status errors. - Move read/write/list/range-scan retry handling into the RPC provider, with callback-based consumers for streaming list/range-scan responses. - Remove the legacy `LeaderHint` protobuf message and use `ErrorInfo` metadata for shard/leader hints. - Clean up batch read/write retry code so batches call the provider once and keep only reroute handling. ## Testing - `go test ./oxia/internal/batch ./oxia -count=1` - `go test ./common/constant ./common/rpc ./oxia/internal/... ./oxia -count=1` - `go test -race ./tests/assignments -run 'TestLeaderHint(ListWithClient|RangeScanWithClient|WithClient)' -count=1` - `go test -race ./tests/assignments -count=1` - `go work edit -json | jq -r '.Use[].DiskPath' | xargs -I{} golangci-lint run {}/...` Split from: https://github.com/oxia-db/oxia/pull/1117 --------- Signed-off-by: mattisonchao <mattisonchao@gmail.com>

2026-05-05

fix: keep metadata codec compatible (#1105) ## Motivation - Keep metadata storage compatible with existing Kubernetes ConfigMap status/config documents and Raft JSON status documents while moving storage-specific codec logic out of `common/proto`. - Preserve rollback compatibility with v0.16.3 metadata readers for the supported Kubernetes and Raft paths. ## Modifications - Moved metadata codecs into `oxiad/coordinator/metadata/common/codec` and split status/config codec logic into separate files. - Updated metadata providers, coordinator code, and tests to import the codec package explicitly. - Changed shard status and split phase metadata fields to protobuf enums while preserving the existing enum names and numeric values. - Kept status YAML serialization numeric for v0.16.3 Kubernetes ConfigMap rollback compatibility, while keeping status JSON serialization string-based for v0.16.3 Raft/JSON rollback compatibility. - Removed legacy file-provider status envelope decoding from the status codec; file status compatibility is intentionally not preserved in this PR. - Moved codec compatibility tests from `common/proto` into the metadata codec package and added explicit JSON/YAML enum compatibility coverage. ## Testing - `go test ./oxiad/coordinator/metadata/common/codec -run 'TestDecodeClusterStatusJSONCompatibility|TestEncodeClusterStatusJSONCompatibility|TestEncodeClusterStatusYAMLRoundTrip|TestDecodeClusterStatusYAMLV0163Compatibility' -count=1` - `go test ./common/proto ./oxiad/coordinator/metadata/...` - `make lint` - `make license-check` - `git diff --check` - Generated v0.16.3 Kubernetes status/config samples and decoded them with the current metadata codecs. Status ConfigMap YAML decodes correctly; legacy namespace `policy.antiAffinities` is intentionally not migrated.

refactor: move namespace anti-affinities out of policy (#1101) ## Motivation - `HierarchyPolicies` only wrapped namespace anti-affinity rules and is not worth preserving before release. - Keeping anti-affinities directly on `Namespace` makes placement policy data simpler for metadata and runtime callers. - Namespace anti-affinity patching needs a namespace-local presence marker because proto3 repeated fields cannot distinguish omitted from empty. ## Modifications - Removed the `HierarchyPolicies` proto message and replaced `Namespace.policy` with `Namespace.anti_affinities`. - Added optional `Namespace.update_anti_affinities` so callers can explicitly set or clear namespace anti-affinities on patch without adding request-level state. - Added admin CLI support for namespace anti-affinities: use `--anti-affinity=labels=mode` to set/replace and bare `--anti-affinity` to clear on patch. - Added validation for anti-affinity labels and modes. - Updated shard placement selectors to consume namespace anti-affinities directly. ## Testing - `go test ./common/proto` - `go test ./cmd/common/parse ./cmd/admin/namespace/... ./common/proto ./oxia ./oxiad/coordinator ./oxiad/coordinator/metadata ./oxiad/coordinator/runtime/balancer/... ./tests/balancer` - `make lint` - `make license-check` - `git diff --check`

2026-05-04

feat: add hierarchy policy admin API Signed-off-by: mattisonchao <mattisonchao@gmail.com>

fix: normalize metadata proto field names (#1099) ## Motivation - Metadata protobuf field declarations used lower-camel identifiers in `metadata.proto`, which does not match protobuf field naming conventions. - The change preserves protobuf wire compatibility by keeping all field numbers unchanged, and preserves existing proto JSON/YAML names through generated `json=...` aliases. ## Modifications - Renamed metadata proto field declarations to lower_snake_case. - Regenerated `common/proto/metadata.pb.go` so descriptors and struct tags expose the corrected proto field names and existing lower-camel JSON aliases. ## Testing - `go test ./common/proto ./oxiad/coordinator/metadata/provider/...` - `go test ./common/...` - `git diff --check` - `make test` attempted and failed in the existing race-enabled suite: - `github.com/oxia-db/oxia/tests/balancer` failed. - `github.com/oxia-db/oxia/tests/coordinator` failed with a Go race detector report in `oxiad/coordinator/metadata/provider/file/provider.go`, involving `loadLatestOnce` reading `p.lastModified` around line 157 and `Store` writing it around line 181.

feat: add delete namespace admin API (#1097) ## Motivation - Continue the namespace admin API rollout by adding namespace deletion. - Allow admin callers to remove namespace configuration while existing reconciler/runtime cleanup handles shard teardown asynchronously. ## Modifications - Added `DeleteNamespace` to the admin proto, generated stubs, public admin client, coordinator metadata, and management server. - Added `oxia admin namespace delete <namespace>` with namespace validation and standard namespace output formats. - Updated admin mocks and coordinator metadata mocks for the new API surface. - Extended namespace admin integration coverage to create, patch, list, delete, and list again. ## Testing - `go test ./cmd/admin/namespace/... ./oxia ./oxiad/coordinator ./oxiad/coordinator/reconciler ./oxiad/coordinator/runtime/balancer ./tests/coordinator -run 'Test_cmd_deleteNamespace|TestAdminClientDeleteNamespace|TestManagementServerDeleteNamespace|TestAdminNamespaceCreateAndGet' -count=1` - `go test ./cmd/admin/... ./oxia ./oxiad/coordinator/...` - `make lint` - `make license-check` Signed-off-by: mattisonchao <mattisonchao@gmail.com>

feat: add patch namespace admin API (#1096) ## Motivation - Continue the namespace admin API rollout by supporting safe partial namespace configuration updates. - Keep namespace create and patch CLI behavior aligned through shared field handling without exposing immutable patch fields. ## Modifications - Added `PatchNamespace` to the admin proto, generated stubs, public admin client, coordinator metadata, and management server. - Added `oxia admin namespace patch <namespace>` with partial update support for replication factor and notifications. - Disallowed patching immutable namespace fields, including initial shard count and key sorting, at both CLI and RPC validation layers. - Reused namespace CLI field definitions between create and patch commands. - Added unit and integration coverage for the client, CLI, management server, and coordinator namespace admin flow. ## Testing - `go test ./cmd/admin/namespace/... ./oxia ./oxiad/coordinator ./tests/coordinator -run 'Test_cmd_patchNamespace|TestAdminClientPatchNamespace|TestManagementServerPatchNamespace|TestAdminNamespaceCreateAndGet' -count=1` - `go test ./cmd/admin/... ./oxia ./oxiad/coordinator/...` - `go test ./tests/coordinator -count=1` - `make lint` - `make license-check` --------- Signed-off-by: mattisonchao <mattisonchao@gmail.com>

feat: add create namespace admin API (#1095) ## Motivation - Add the namespace create endpoint to continue the admin management API rollout. - Align namespace creation with the existing dataserver create flow across proto, coordinator, public client, and CLI. ## Modifications - Added `CreateNamespace` to the admin proto, generated stubs, and public `oxia.AdminClient`. - Added coordinator metadata/server support with validation, duplicate detection, bad-version handling, and replication-factor precondition mapping. - Added `oxia admin namespace create <namespace>` with required `--initial-shards` and `--replication-factor` flags plus notifications/key-sorting options. - Added unit coverage for admin client, management server, namespace CLI, and an integration test for create/get/list through the admin client. ## Testing - `go test ./cmd/admin/namespace/... ./oxia ./oxiad/coordinator ./oxiad/coordinator/reconciler ./oxiad/coordinator/runtime/balancer ./tests/coordinator` was interrupted after the full coordinator e2e package made no progress for several minutes; the preceding packages passed. - `go test ./tests/coordinator -run TestAdminNamespaceCreateAndGet -count=1 -timeout=2m` - `go test ./cmd/admin/... ./oxia ./oxiad/coordinator/...` - `make lint`

feat: add namespace get admin API (#1094) ## Motivation - Align namespace admin reads with the dataserver-style get API that returns the full entity. - Replace the legacy string-only namespace list path with entity-based get/list behavior under `namespace get`. ## Modifications - Added `GetNamespace` to the admin proto, generated stubs, public admin client, and coordinator management server. - Updated `ListNamespaces` to return full `Namespace` entities and removed the legacy `list-namespaces` CLI. - Added `oxia admin namespace get [namespace]`: with a name it returns that namespace; without a name it lists namespaces and defaults to `name` output. - Added unit coverage for the server, admin client, namespace CLI, and nil namespace output validation. ## Testing - `go test ./cmd/admin/namespace/... ./oxia ./oxiad/coordinator` - `go test ./cmd/admin/... ./oxia ./oxiad/coordinator/...` - `make lint`

feat: add delete data server admin API (#1093) ## Motivation - Add the admin dataserver delete operation so configured dataservers can be removed through the public management API and CLI. - Keep this scoped to configuration deletion; decommission/drain readiness remains a separate lifecycle concern. ## Modifications - Added DeleteDataServer to the admin proto, generated clients, public admin client, coordinator management server, and coordinator metadata. - Added the `oxia admin dataserver delete <name>` CLI command. - Added unit coverage plus a coordinator integration test that starts from an empty file-backed cluster and exercises create, read, patch, and delete via the admin API. ## Testing - `go test ./cmd/admin/... ./oxia ./oxiad/coordinator/...` - `go test ./tests/coordinator -run TestAdminDataServerCRUD -count=1` - `go test ./tests/coordinator` - `make lint`

feat: add patch data server admin API (#1092) ## Motivation - Support updating existing data server configuration through the admin API and CLI. - Keep patch behavior sparse so callers can update public address, internal address, or labels independently. ## Modifications - Add `PatchDataServer` to the admin proto, generated bindings, Go admin client, coordinator management server, and metadata layer. - Add `oxia admin dataserver patch <name>` with shared data server flag handling for `--public`, `--internal`, and `--label`. - Map metadata patch failures to standard gRPC status codes for not found, concurrent config updates, and internal errors. ## Testing - `make lint` - `go test ./cmd/admin/... ./oxiad/coordinator/...`

feat: add create dataserver admin API (#1091) ## Motivation - add an admin API for creating data servers through coordinator-managed cluster configuration - expose the same capability through the Go admin client and CLI - return provider/config conflicts as normal errors so the management server can map them to standard gRPC codes ## Modifications - added `CreateDataServer` to the admin gRPC API and regenerated the admin protobuf bindings - added a metadata config mutation for creating data servers and updated provider store paths to return `ErrBadVersion` instead of panicking - implemented coordinator `CreateDataServer` request validation and response/error mapping - added `CreateDataServer` to the Go admin client and mock client support - added `oxia admin dataserver create <name> --public ... --internal ... [--label key=value]` ## Testing - `go test ./oxiad/coordinator ./oxiad/coordinator/metadata ./oxia ./cmd/admin/...` - `make lint`

2026-05-03

feat: add create dataserver admin API

refactor: remove deprecated list nodes admin API (#1087) ## Motivation - remove the deprecated `ListNodes` admin RPC instead of carrying a compatibility endpoint and CLI alias - keep the coordinator admin surface aligned with the current `DataServer`-based API ## Modifications - removed `ListNodes` request/response messages and RPC from `common/proto/admin.proto` - regenerated the admin protobuf and gRPC bindings after the RPC removal - removed the deprecated admin client `ListNodes` method and the `Node` compatibility types - removed the coordinator `ListNodes` management handler and its test coverage - removed the deprecated `admin list-nodes` CLI command and related mock/test code ## Testing - `go test ./oxia ./cmd/admin/... ./oxiad/coordinator/...` - `make license-check` - `make lint`

2026-04-24

refactor: rename dataserver identity model (#1056) ## Motivation - Make `DataServer` represent the managed data-server resource. - Rename the embedded endpoint/name payload so the protobuf model is clearer before adding coordinator domain APIs. ## Modifications - Rename the embedded protobuf message from `DataServer` to `DataServerIdentity`. - Rename `DataServerInfo` to `DataServer` and the nested `dataServer` field to `identity`. - Update coordinator, admin client, tests, codecs, and generated protobuf call sites to use the new names. ## Testing - `go test ./cmd/admin/dataserver ./cmd/admin/dataserver/get ./cmd/admin/dataserver/list ./common/proto ./oxia ./oxiad/coordinator -count=1` - `make lint` - `make license-check`

refactor: move coordinator status to metadata proto (#1054) ## Motivation - move coordinator status to the protobuf metadata model so config and status share the same canonical representation - remove the remaining coordinator runtime dependency on the old status/common Go model ## Modifications - add protobuf status messages and codecs in `common/proto` - migrate coordinator, selectors, actions, providers, dataserver integration points, and tests to use protobuf status and dataserver types - delete the old coordinator status/common model files and the remaining conversion helper package ## Testing - `go test ./tests/coordinator -run 'TestCoordinator_LeaderFailover$|TestCoordinator_DynamicallAddNamespace$|TestCoordinator_ShardSplit$|TestCoordinator_KeySorting$' -count=1 -timeout 240s` - `go test ./common/... ./oxiad/... ./cmd/... ./oxia/... ./tests/... -run '^$'` - `make lint` - `make license-check`

refactor: move coordinator status to metadata proto

2026-04-23

refactor: move coordinator configuration to metadata proto (#1052) ## Motivation - make protobuf the primary coordinator configuration model so admin and configuration use the same types - remove the legacy coordinator config model and config package for cluster configuration - keep existing YAML/JSON configuration compatible while moving the runtime code to the new proto model ## Modifications - add `common/proto/metadata.proto` and move the coordinator configuration types into protobuf - rename the config model types to `ClusterConfiguration`, `Namespace`, and `HierarchyPolicies` - switch coordinator/admin/config-related code to use the protobuf model directly - add compatibility encode/decode helpers and tests for YAML/JSON loading and YAML round-tripping - preserve admin dataserver compatibility behavior for unnamed servers by returning the identifier as the effective name - delete the old cluster-config Go model and remove `oxiad/coordinator/config` ## Testing - `go test ./oxiad/coordinator -run 'TestAdminServer|TestDecode|TestEncode' -count=1` - `go test ./oxiad/coordinator/balancer ./oxiad/coordinator/util -count=1` - `go test ./tests/balancer ./tests/control ./tests/assignments ./tests/security/tls ./tests/security/auth ./tests/resolver -count=1` - `go test ./tests/coordinator -run 'TestCoordinatorE2E$|TestCoordinator_LeaderFailover$' -count=1 -timeout 180s`

2026-04-22

refactor: move configuration compatibility into metadata proto

refactor: move coordinator configuration to metadata proto

2026-04-21

feat: add dataserver instance-id handshake and internal RPC validation (#1048) ## Motivation - prevent internal coordination and replication RPCs from crossing coordinator instances after dataservers have local state - bind each dataserver to a coordinator-owned persisted `instance_id` instead of relying on endpoint authority for internal traffic - keep rolling upgrades working while moving dataserver initialization away from `GetInfo` ## Modifications - added `Handshake` to the coordination RPC API, deprecated `GetInfo` for removal in the next major version, and persisted a cluster-wide `instance_id` in coordinator status - added a dataserver `MANIFEST` file to persist the bound `instance_id`, with dataservers staying uninitialized until handshake succeeds - validated internal coordination and replication RPCs with `instance-id` metadata, while keeping health and handshake open for bootstrap - moved coordinator RPC clients to factory-based construction and updated tests, mocks, and helpers to use the new provider ownership model - kept rolling-upgrade compatibility by falling back from `Handshake` to deprecated `GetInfo` when talking to older dataservers ## Testing - `go test ./common/rpc -count=1` - `go test ./tests/coordinator -run 'TestCoordinatorE2E$|TestCoordinatorE2E_ShardsRanges$|TestCoordinator_LeaderFailover$' -count=1 -timeout 180s` - `go test ./tests/assignments ./tests/control ./tests/resolver -count=1 -timeout 180s` - `go test ./tests/security/auth ./tests/security/tls -count=1 -timeout 180s` - `go test ./common/... ./oxiad/... -count=1`

2026-04-17

refactor: rework metadata v2 document store

2026-04-16

commit changes

feat: commit changes

define the interface

fix: add dataserver get admin command (#1045) ## Motivation - align the new data-server lookup command with the existing `oxia admin dataserver ...` command shape - allow users to fetch a data server by either its configured name or its internal-address fallback ## Modifications - add `GetDataServer` to the admin API and wire it through the admin client and mocks - expose the command as `oxia admin dataserver get <data-server>` - match data servers by configured name or internal address in the coordinator admin server - regenerate the admin protobuf stubs and add coordinator/client/CLI test coverage ## Testing - `GOPATH=$(go env GOPATH) make -C /tmp/oxia-pr1037-v2 proto` - `go test ./cmd/admin/... ./oxia ./oxiad/coordinator` - `go run ./cmd admin dataserver --help`

2026-04-14

feat: allow extra authorities from cluster config (#1040) ## Summary - add to cluster config with authority validation - publish accepted authorities on top-level - make dataserver authority validation consume the assignment-level authority set ## Details This keeps authority acceptance cluster-config driven instead of dataserver-config driven. The coordinator now merges leader public/internal addresses with cluster-level extra authorities into the shard assignment snapshot, and dataservers validate incoming against that assignment payload. ## Testing - go test ./oxiad/coordinator/model ./oxiad/coordinator ./oxiad/dataserver/assignment ./oxiad/dataserver

2026-04-13

Add ListDataServers admin endpoint (#1036) ## Summary - add the first data server management RPC, `ListDataServers` - return configured data server identity with `name`, `public_address`, and `internal_address` - expose the new endpoint through the public admin client and add the matching admin CLI command and tests ## Testing - go test ./oxiad/coordinator ./oxia ./cmd/admin/...

2026-03-20

feat: add data server support for shard split observers and snapshots (#945) Implement observer follower cursors that replicate data from a parent shard to child shards during split operations: - Observer cursors using the parent's term for proper term validation on the receiving child (coordinator fences child with parent's term) - SendSnapshot/Replicate flow for shard-to-shard data bootstrap - Hash range propagation via gRPC metadata so child followers activate receiver-side filtering (SetSplitHashRange) - FilterDBForSplit and ApplyLogEntryWithSplitFilter for key filtering based on hash range boundaries - RemoveObserver RPC: cleanly remove observer cursors from parent leader without fencing, used during split abort Extend quorum ack tracker to support adding/removing followers dynamically during split lifecycle. Add follower controller support for receiving observer snapshots and replication streams. --------- Signed-off-by: Matteo Merli <mmerli@apache.org>

2026-03-03

feat: add shard split proto definitions, model types, and admin CLI (#911) Design detailed in https://github.com/orgs/oxia-db/discussions/909 ### Change 1/3 Add the foundational types and interfaces for shard splitting: - Proto: SplitShard RPC in admin service, AddFollowerRequest.observer and target_shard fields in replication service - Model: SplitPhase enum (Init/Bootstrap/CatchUp/Cutover/Cleanup), SplitMetadata, ShardStatusDeleting, DeleteShardMetadata helper - Client: SplitShard method on Admin interface and implementation - CLI: `oxia admin split-shard` command - Admin server: SplitShard handler that delegates to coordinator Signed-off-by: Matteo Merli <mmerli@apache.org>

2026-02-24

fix: propagate WAL CRC chain across snapshot recovery (#901) ### Motivation When a follower installs a snapshot, `wal.Clear()` resets the CRC chain to 0. Since `CRC(n) = CRC32(CRC(n-1) + payload(n))`, all subsequent WAL CRCs diverge from the leader even though the DB data is identical (fixes #898). ### Modification - Add `previous_entry_crc` field to the `Append` protobuf message for CRC propagation during replication. - Expose `previousCrc` through the WAL read chain (`ReadRecordWithValidation` → `segment.Read` → `wal.readAtIndex` → `Reader.ReadNext`) so the leader can include it in every `Append` message. - Add `AppendAsyncWithPreviousCrc(entry, previousCrc)` to the `Wal` interface so the follower can seed the CRC chain when appending after snapshot install. - Preserve the caller's CRC seed in `readWriteSegment` when `RecoverIndex` returns an empty segment. - Add `U32Zero` constant to `common/constant` for typed zero CRC values. - Add `TestReadNextReturnsCrc` and `TestAppendAsyncWithPreviousCrc` WAL tests. - Update `TestFollowerCursor_SendSnapshot` to verify non-zero `PreviousEntryCrc` after snapshot.

2026-02-23

feat: add checksum gauge metric and move checksumInterval to storage level (#890) ### Motivation The `RecordChecksumRequest` WAL entry was a no-op marker that never actually recorded the DB checksum as a metric. ### Modification - Add `SyncGauge` metric type (non-callback based) to `common/metric/gauge.go` - Add `RecordChecksumRequest` to the `ControlRequest` proto oneof - Add `oxia_dataserver_db_checksum` gauge to both leader and follower controllers - `ControlProposal.Apply()` and `ApplyLogEntry()` now read and return the DB checksum via `ApplyResponse.Checksum` when processing a `RecordChecksumRequest` - Leader records the gauge after `proposal.Apply()` in the generic propose path - Follower records the gauge after `ApplyLogEntry()` in the committed entries path - Add `checksum_scheduler.go` to periodically trigger checksum recording - Add `scheduler.checksum.interval` config option - Add integration test verifying checksum metric appears with correct labels and changes after additional writes

2026-02-22

feat: replicate control requests through WAL via state machine (#882) ### Motivation Enable the leader to replicate control commands (e.g., feature enablement) through the WAL alongside regular writes, so that features negotiated between replicas are applied consistently across all nodes via the replication log rather than in-memory state. ### Modification - Add `ControlRequest` and `FeatureEnableRequest` protobuf messages to the `LogEntryValue` oneof, allowing control commands to be serialized into WAL entries alongside write requests. - Introduce a `statemachine` package with a `Proposal` interface (`WriteProposal`, `ControlProposal`) where each proposal type knows how to serialize itself to a log entry and apply itself to the DB. - Add `ApplyLogEntry` function for the follower/replay path that deserializes and applies WAL entries. - Refactor leader controller: rename `write` to `propose` to reflect the generalized proposal flow, split `BecomeLeader` to propose feature enablement outside the lock, and delegate to `proposal.Apply()` after quorum ack. - Refactor follower controller: replace inline write-processing with `statemachine.ApplyLogEntry`, hold read lock during apply, and expose `IsFeatureEnabled`/`Checksum` methods. - Make DB checksum computation opt-in via `EnableFeature(FEATURE_DB_CHECKSUM)` — checksum is only computed when the feature is enabled or a non-zero checksum already exists. - Use read locks instead of exclusive locks for read-only operations (`Checksum`, `ApplyLogEntry` on follower, `IsFeatureEnabled` on leader). - Rename `FEATURE_FINGERPRINT` to `FEATURE_DB_CHECKSUM`. - Add unit tests for state machine and proposal logic, and an integration test verifying feature enablement replication and checksum consistency across 3 replicas.

feat: support leader hint when NodeIsNotLeader (#883) ### Motivation When a client sends a request to a non-leader node, the retry relies on the shard manager's assignment mapping, which may be stale. This PR enriches the `NodeIsNotLeader` gRPC error with a leader hint so the client can retry directly to the correct leader, reducing retry latency during leadership changes. ### Modification - Add `LeaderHint` protobuf message and embed it as gRPC status detail in `NodeIsNotLeader` errors. - Add `shardAssignmentsIndex` on the assignment dispatcher for O(log n) shard-to-leader lookup. - Extract leader hint on the client side and use it in read/write batch retry paths. - Invalidate cached write streams when a leader hint is present, with proper cleanup of old streams. - Remove unneeded goroutine for write stream context watching. - Add `WithFailureInjection` client option and `DizzyShardManager` for testing. - Add integration tests for leader hint with and without client.

2026-02-04

feat: support negotiated features (#878) ### Motivation This is part 2 of https://github.com/orgs/oxia-db/discussions/849. The PR introduces the negotiated support features for the ensemble DataServer to avoid any unexpected behaviour when rolling out an upgrade or a different version. ### Modification - Added Feature enum and GetInfo RPC to protocol - Coordinator collects and negotiates features during election - Leader stores negotiated features and exposes IsFeatureEnabled() - Old nodes without GetInfo are treated as supporting no features

2026-01-29

Allow to override version id and modification count (#872) During migrations to Oxia, it would be useful to preserve the original version id and modification counts of records. This will only be exposed in Java client API. Signed-off-by: Matteo Merli <mmerli@apache.org>

2025-11-22

Moved `proto` under `common/proto` (#824) Move proto inside common module, so we have one fewer externally exposed module --------- Signed-off-by: Matteo Merli <mmerli@apache.org>

Allow to configure key-sorting natural/hierarchical on namespaces (#818) Added ability to select key sorting on namespaces. By default, we will continue to use the "hierarchical" sorting. At some point, the default might get switched. --------- Signed-off-by: Matteo Merli <mmerli@apache.org> Co-authored-by: Qiang Zhao <mattisonchao@apache.org> Co-authored-by: mattisonchao <mattisonchao@gmail.com>

2025-11-21

Hide internal keys by default in list and range-scan (#810) When doing list, range-scans and non exact get queries, hide by default all the internal keys used by Oxia. CLI can still require to list the internal keys. --------- Signed-off-by: Matteo Merli <mmerli@apache.org> Co-authored-by: mattisonchao <mattisonchao@gmail.com>

2025-11-08

Add listnodes admin tool (#800) Add listnodes admin tool --------- Signed-off-by: dao-jun <daojun@apache.org>

2025-10-28

[feat][admin] Initial Oxia admin commit and add list-namespaces command. (#792) Add oxia admin ist-namespaces command. --------- Signed-off-by: dao-jun <daojun@apache.org>

2025-10-11

Rename public gRPC to io.oxia.proto.v1.OxiaClient (#756) Renaming the public gRPC service from `io.streamnative.oxia.proto.OxiaClient` to `io.oxia.proto.v1.OxiaClient`. This needs to be done in phases: 1. (this PR) change the server to support both service names 2. Update clients so that will start use new namespace 3. Once all clients are upgraded, remove the compatibility layer --------- Signed-off-by: Matteo Merli <mmerli@apache.org>

Switched Copyright to "The Oxia Authors" (#755) Signed-off-by: Matteo Merli <mmerli@apache.org>

2025-09-09

step commit

2025-08-13

Squashed commit of the following: commit 208100dc6dff5d94289fa0f3ff8c023f67bc2c6e Author: mattisonchao <mattisonchao@gmail.com> Date: Wed Aug 13 21:43:33 2025 +0800 fix failed test commit e682bfdd0148859a5ac7c19aa3420ef3646ee52d Author: mattisonchao <mattisonchao@gmail.com> Date: Wed Aug 13 21:36:12 2025 +0800 fix compile error commit 3536ac9ac68774c2e3e91eb4f8240893fb853fb9 Author: mattisonchao <mattisonchao@gmail.com> Date: Wed Aug 13 21:32:47 2025 +0800 fix lint commit 1a1e75a20b148448651e704c0d4d42fdf7941af2 Author: mattisonchao <mattisonchao@gmail.com> Date: Wed Aug 13 21:23:31 2025 +0800 fix tests commit a6cd17d851ee6648d5f81360b75d651f6a859bdf Author: mattisonchao <mattisonchao@gmail.com> Date: Wed Aug 13 20:49:11 2025 +0800 add missing changes commit 61dc26ef00b8148b842e5267713060a97694ab07 Author: mattisonchao <mattisonchao@gmail.com> Date: Wed Aug 13 19:59:05 2025 +0800 feat: support follower read

feat: support follower read

2025-06-18

Updates repo URL to github.com/oxia-db/oxia (#721)

2025-05-21

Support Get() operation using secondary index (#686) Allow to specify a `UseIndex()` option on `Get()` operations. The key is then compared with the selected secondary index. It works also with `ComparisonLower()`, `ComparisonHigher()` etc..

2025-05-19

[feature] Get Key sequence updates. Server side implementation (#687) Allows client to select to be notified whenever a new key sequence is generated for a given prefix key.

2025-04-11

step commit

step commit

step commit

2024-10-24

fix: fix assignment lost when restart node

2024-10-08

Allow to pass the same secondary index name multiple times on the same record (#546)

2024-10-03

Protobuf changes for secondary indexes (#541)

2024-09-25

On delete-range send 1 single notification to clients (#532) When there is a delete-range request, we are currently sending 1 `deleted` notification for each of the keys that were deleted in the range. The problem is that the number of keys in the range is unbounded and can lead to a huge batch in the DB and also to a big notification batch to send out to client. It's not easy to split the notification batch, since it needs to be written atomically with the db update itself. Instead, we add a new notification type that will simply tell the client that a range of keys was deleted.

2024-09-23

Allow to disable notifications on a namespace (#526) This is part-1 of the changes. It adds the option to configure a namespace with notifications disabled. If a use case only needs key-value semantics and doesn't use notifications, we can disable them to avoid the overhead. (Part-2 will use the configuration to implement the notifications skipping).

2024-09-13

Rename ShardId field to Shard (#511) Renaming the protobuf field from `ShardId` to `Shard`. The motivation is to have consistent `shard: 123` in the logs, such that filtering them based on shard becomes easier. All logs context are already using the `shard` label, though when we print Protobuf struct directly, it would today have `shardId`.

2024-07-28

Added server side support for WriteStream operation (#499)

2024-05-18

Added range-scan support in oxia db (#479)

2024-05-16

Support sequential write operation on server dbs (#472)

2024-05-15

Added partition-key to override shard routing (#470)

2024-05-14

Server side handling of floor/ceiling get requests (#467)

2024-01-05

*: Update license

2023-07-22

Use VT proto for serialization (#366) Using https://github.com/planetscale/vtprotobuf for adding extra methods to the generated Protobuf code. The extra marshallVT/unmarshallVT methods are generated as "rolled-out" code instead of using reflection so they're using much less CPU and memory allocations. It's also capable of generating hooks for getting objects from pool.

2023-04-12

Include head & commit offset in GetStatus (#326)

2023-03-30

Added server side support for deleting shards (#299)

2023-03-23

Changed shard id type to int64 (#296) With namespaces, we'll be able to create and delete shards. It will be safer to use `int64` rather than `uint32` to avoid having to deal with any rollover.

2023-03-22

Passing namespace to server components for metrics and logs (#292)

2023-03-21

Added namespace into assignments dispatcher (#291)

2023-03-20

Added support in coordinator for multiple namespaces (#289) Added concept of "default" namespace. `ReplicationFactor` and `InitialShardsCount` are now moved at the namespace level.

2023-02-24

Make KeepAlives non-streaming (#267)

2023-02-08

Streaming read (#257)

2023-02-01

Remove batched list (#250) stacked on #245 diff: https://github.com/nahguam/oxia/compare/add-list-rpc...nahguam:oxia:remove-batched-list?expand=1

Split List out to separate streaming rpc (#245)

2023-01-28

Added client identity (#249) Added concept of client identity in the API: 1. A client can pass an optional `Identity` option (string). If none is passed, a UUID is internally generated 2. A session is tied to a particular client's identity 3. The client identity is the same across all the shards 4. The identity is exposed in the `Version` object (for ephemeral records) 5. Applications can make several uses of client identity: 1. Specify the client identity as in "node-port" of a particular service 2. Debug to know who created an ephemeral record 3. Allow creating more complex abstractions by identifying "was this record created by me?" 4. Maintain the identity across restarts of the same applications (e.g.: restart a pod that comes back up with the same name and will use the same client identity). There will be no effort from Oxia to disallow conflicting identities, though they should be discouraged.

2023-01-25

Add batching in the leader, before writing to WAL (#237)

2023-01-24

Renamed Payload -> Value (#239) Co-authored-by: Dave Maughan <dave.maughan@streamnative.io>

2023-01-20

Renamed Stat -> Version (#233) 1. Renaming the concept of `Stat` to `Version` object 2. Changed `Version` field into `VersionId` which represents the offset when the record was modified 3. Added `ModificationsCount` field to let users know how many changes since the record was last created Co-authored-by: Dave Maughan <dave.maughan@streamnative.io>

Renamed Fence -> NewTerm (#232) Co-authored-by: Dave Maughan <dave.maughan@streamnative.io>