3.8.1

Date: 2026-09-01 Tag: 3.8.1

Overview

Tarantool 3.x is the recommended release series. Users of Tarantool 2.11 are encouraged to update to the latest 3.x release.

This release introduces 1 improvement and resolves 15 bugs since 3.8.0.

Please consider the full list of user-visible changes below.

Compatibility

Tarantool 2.x and 3.x are compatible in the binary data layout, client-server protocol, and replication protocol. It means upgrade may be performed with zero downtime for read requests and the order-of-network-lag downtime for write requests.

Please follow the upgrade procedure to plan your update actions.

Users of Tarantool 2.x may be interested in the compat options that allow to imitate some 2.x behavior. This allows to perform application code update step-by-step, not all-at-once.

Functionality added or changed

Core

• Added a new box.cfg.read_only value: 'unless_bootstrap'. An instance configured this way becomes writable only if it has bootstrapped the replica set on the current startup and stays read-only if it has recovered from a local snapshot or has joined an already bootstrapped replica set. The mode is resolved atomically during the initial box.cfg() call, so the instance never goes through a transient writable state. The value may be set only during the initial box.cfg() call (gh-12970).

Although this change brings a new feature rather than a bugfix, it was decided to backport it anyway, because the new option value is used by the config module to fix a serious double-leader bug with 'supervised' failover. More details below in the "Config" section and in the gh-12970 issue.

Bugs fixed

Application server

• Fixed a bug where Tarantool could hang at startup when application threads were configured (gh-12936).
• The root directory from which Lua dependencies are loaded was made global: setting it with package.setsearchroot() in tx or any of the application threads now affects all application threads and tx (gh-12546).

Core

• Fixed a crash on calling box.ctl.wal_sync() before box.cfg{}. Now it raises an ER_UNCONFIGURED error in this case (gh-12556).
• Fixed a crash on update with deleting by JSON path with a terminal key when the deleted key in the tuple had non-optimal encoding (gh-13027).

Vinyl

• In some cases, vinyl deferred UPSERT field constraint checks until a read or a compaction. A violating UPSERT could then be skipped without returning an error to the client. Constraints are now validated at UPSERT time when update operations may modify constrained columns, matching Memtx behavior (gh-12404).

Replication

• Fixed an ordering bug in WAL batching that could make a joining replica miss rows written by the master (gh-11028).

Lua

• Fixed an error in the JSON encoder when an encoded key in the map has the __serialize metamethod (gh-12726).

Http client

• Fixed a regression of authorization on an HTTP proxy or a target HTTP(S) host using the Basic algorithm (gh-12805).

SQL

• Fixed an inability to set both the sort order and the AUTOINCREMENT property on columns in a PRIMARY KEY table constraint at the same time (gh-12968).
• Fixed a bug where the foreign field ID for a field foreign key was lost after executing an ALTER TABLE ADD COLUMN statement (gh-13010).
• Added permission checks when dropping a trigger in SQL. Now only users with 'alter' privileges on a table can drop triggers for that table (ghs-163).

Config

• This is the bugfix that needs the unless_bootstrap feature described above. Fixed a bug where an instance rebootstrapped with an empty data directory could start in the RW mode alongside an already appointed leader with replication.failover = supervised and replication.bootstrap_strategy = auto, if the instance had the lexicographically minimal name in the replica set. The bootstrap leader candidate now starts with box.cfg.read_only = 'unless_bootstrap', so a rejoined instance never goes through a writable state at all (gh-12970).
• Fixed a spurious The vshard-ee/vshard module is not available configuration validation error on startup when the vshard module is installed into the configured process.work_dir and the process is started from a different directory, or when an instance without a sharding role inherits a global sharding option, such as sharding.bucket_count. The availability of vshard and its minimum version are now checked only on instances with a configured sharding role (gh-12928, gh-13025).
• Modules installed into the configured process.work_dir (for example, into its .rocks directory) are now resolvable, and a relative app.file path is interpreted against the working directory even before the first box.cfg() call. In particular, roles and an application marked with the early_load tag can now be loaded from the working directory, and the configuration defaults that depend on the installed vshard version are applied at first startup (gh-13025).
• An unavailable or outdated vshard module for a configured sharding role, as well as a configured sharding option that requires a newer vshard, is now reported before the first box.cfg() call, so a misconfigured instance fails fast instead of failing after a potentially long database recovery (gh-13025).