Skip to main content

5.2 Release Notes

Patch Releases​

All patch release notes for 5.2.x are available on the releases page.

Backup & Restore​

New managed-backup operations for RocksDB databases: create_backup, list_backups, verify_backup, delete_backup, purge_backups, and restore_backup. Managed backups are a server-side repository under the configured backup root (storage.backupPath, default <rootPath>/backup); the RocksDB data files are shared and incremental across backups, while the audit/transaction log — and, for databases with file-backed blobs, the blobs (skip with exclude_blobs) — are captured in full on every backup. verify_backup checks the RocksDB files (checksums with verify_checksum) and the transaction-log snapshot; it does not verify blobs. restore_backup restores a user database in place without stopping Harper, as long as no loaded component is holding that database open; a database held open by a component — and always the system database — is restored offline by running restore_backup from the CLI with the server stopped. Each of these operations can be run from the CLI under its operation name (e.g. harper create_backup database=data): while Harper is running the operation is forwarded to the server, and while it is stopped the command operates directly on the files. See Backups and Backup Operations.

get_backup now understands RocksDB: it streams a full-snapshot tar of the database — including any file-backed blobs (pass exclude_blobs: true to omit them), gzipped by default (pass gzip: false for a plain tar) — instead of failing. The LMDB behavior (streaming the .mdb, with table/tables/include_audit) is unchanged.

Querying​

Filtered Vector Search (Predicate-Aware HNSW Traversal)​

Vector searches combined with filters now evaluate the filter during HNSW graph traversal, so the query keeps exploring until it has enough matching nearest neighbors instead of post-filtering a fixed candidate set (which under-filled results under selective filters). Filters can come from query conditions, a JS-API vectorFilter function, or a record-scoped allowRead override — overriding allowRead on a table now makes it a row-level access check, evaluated per record with this bound to the record (closing the gap where a collection scan could return rows a single-record GET would deny). With it, a restricted user's vector search returns the k nearest records they are allowed to see. Very selective conditions automatically use an exact scan instead of graph traversal, and a filterExpansion visit budget bounds traversal cost. See Vector Indexing.

Components​

Scheduler: Recurring Jobs from Component Config​

Components can now declare recurring jobs in their configuration with a new built-in scheduler plugin. Jobs run on a five-field cron expression or a simple interval (90s, 5m, 1h), invoking a designated export from the component. In a cluster, execution is leader-coordinated - under normal operation each occurrence runs once, on an automatically elected leader node - with heartbeat-based failover, catch-up for missed occurrences, and per-job run state recorded in a replicated system table (handlers should be idempotent, as failover can occasionally deliver an occurrence twice; conversely, catch-up only backfills the single most recent missed occurrence, not a full backlog). See Scheduler.

Configuration​

Replicated set_configuration​

The set_configuration operation now accepts "replicated": true to apply a configuration change to all cluster nodes in a single Operations API call, with per-node outcomes reported in the response's replicated array. Only cluster-appropriate parameters should be replicated — see Configuration Operations.

CLI​

Explicit Authentication for Operations API Commands​

CLI Operations API commands now accept dedicated auth_username= and auth_password= parameters, allowing commands such as add_user and alter_user to authenticate as an administrator while keeping the affected user's username= and password= in the operation payload. Environment-variable credentials and saved harper login tokens now take precedence over the legacy username= and password= authentication fallback. Credential pairs are also resolved within one environment-variable namespace, preventing a username from HARPER_CLI_* from being combined with a password from legacy CLI_TARGET_* variables. See CLI Authentication.

HTTP​

Middleware routing and ordering​

Applications can now be routed by virtual hostname, URL prefix, or both, with no dispatch code. Declare host and urlPath on the application's entry in the root harper-config.yaml — or pass them to deploy_component — and every handler the application registers is served under that hostname and path. Because the routing lives in the root config, the same application can be mounted differently per environment without editing it. A plugin's own urlPath still positions it within the application, and the application's mount is prefixed onto it.

Components can also pass host and urlPath directly to server.http(), server.ws(), and server.upgrade(). The new name, before, and after options provide explicit middleware ordering. See HTTP middleware routing and HttpOptions.

Security​

Web Application Firewall​

Harper Pro now includes a Web Application Firewall that evaluates rule-based IP/CIDR, method, path, header, and query conditions before authentication and application routing. Rules support block, log, and score actions; cluster-wide monitor and off modes; per-rule shadowing; node activation gates; live replicated updates; and RE2-backed regular expressions. See Web Application Firewall.