Known Issues in ArangoDB 3.9

This page lists important issues affecting the 3.9.x versions of the ArangoDB suite of products. It is not a list of all open issues.

Critical issues (ArangoDB Technical & Security Alerts) are also found at arangodb.com/alerts.

ArangoSearch

Issue
Date Added: 2018-12-19 Component: ArangoSearch Deployment Mode: Single-server Description: Value of `_id` attribute indexed by ArangoSearch view may become inconsistent after renaming a collection Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: arangodb/backlog#514 (internal)
Date Added: 2018-12-03 Component: ArangoSearch Deployment Mode: Cluster Description: Score values evaluated by corresponding score functions (BM25/TFIDF) may differ in single-server and cluster with a collection having more than 1 shard Affected Versions: 3.4.x, 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: arangodb/backlog#508 (internal)
Date Added: 2018-12-03 Component: ArangoSearch Deployment Mode: All Description: Using a loop variable in expressions within a corresponding SEARCH condition is not supported Affected Versions: 3.4.x, 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: arangodb/backlog#318 (internal)
Date Added: 2019-06-25 Component: ArangoSearch Deployment Mode: All Description: The `primarySort` attribute in ArangoSearch View definitions cannot be set via the web interface. The option is immutable, but the web interface does not allow to set any View properties upfront (it creates a View with default parameters before the user has a chance to configure it). Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: N/A
Date Added: 2020-03-19 Component: ArangoSearch Deployment Mode: All Description: Operators and functions in `SEARCH` clauses of AQL queries which compare values such as `>`, `>=`, `<`, `<=`, `IN_RANGE()` and `STARTS_WITH()` neither take the server language (`--default-language`) nor the Analyzer locale into account. The alphabetical order of characters as defined by a language is thus not honored and can lead to unexpected results in range queries. Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: arangodb/backlog#679 (internal)

AQL

Issue

Issue
Date Added: 2018-09-05 Component: AQL Deployment Mode: Cluster Description: In a very uncommon edge case there is an issue with an optimization rule in the cluster. If you are running a cluster and use a custom shard key on a collection (default is `_key`) and you provide a wrong shard key in a modifying query (`UPDATE`, `REPLACE`, `DELETE`) and the wrong shard key is on a different shard than the correct one, a `DOCUMENT NOT FOUND` error is returned instead of a modification (example query: `UPDATE { _key: "123", shardKey: "wrongKey"} WITH { foo: "bar" } IN mycollection`). Note that the modification always happens if the rule is switched off, so the suggested workaround is to deactivate the optimizing rule `restrict-to-single-shard`. Affected Versions: 3.4.x, 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: arangodb/arangodb#6399
Date Added: 2022-08-12 Component: AQL Deployment Mode: Cluster Description: Since ArangoDB 3.8 there was a loophole for creating duplicate keys in the same collection. This was only possible in cluster and needed an AQL query that copied over data from a collection (source) into another (target). The target collection must have more than one shard and must use a custom shard key. Inserting documents into the target collection must have happened via an AQL query like `FOR doc IN source INSERT doc INTO target`. In this particular situation, the document keys (`_key` attribute) from the source collection were used as-is for insertion into the target collection. However, as the target collection is not sharded by `_key` and uses a custom shard key, it is actually not allowed to specify user-defined values for `_key`. Versions before 3.8 failed with the error “must not specify _key for this collection” when running such AQL query, but versions between 3.8.0 and 3.9.2 did not. Affected Versions: 3.8.0 - 3.8.7, 3.9.0 - 3.9.2 Fixed in Versions: 3.8.8, 3.9.3 Reference: arangodb/arangodb#16764

Date Added: 2018-09-05
Component: AQL
Deployment Mode: Cluster
Description: In a very uncommon edge case there is an issue with an optimization rule in the cluster. If you are running a cluster and use a custom shard key on a collection (default is _key) and you provide a wrong shard key in a modifying query (UPDATE, REPLACE, DELETE) and the wrong shard key is on a different shard than the correct one, a DOCUMENT NOT FOUND error is returned instead of a modification (example query: UPDATE { _key: "123", shardKey: "wrongKey"} WITH { foo: "bar" } IN mycollection). Note that the modification always happens if the rule is switched off, so the suggested workaround is to deactivate the optimizing rule restrict-to-single-shard.
Affected Versions: 3.4.x, 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x
Fixed in Versions: -
Reference: arangodb/arangodb#6399

Date Added: 2022-08-12
Component: AQL
Deployment Mode: Cluster
Description: Since ArangoDB 3.8 there was a loophole for creating duplicate keys in the same collection. This was only possible in cluster and needed an AQL query that copied over data from a collection (source) into another (target). The target collection must have more than one shard and must use a custom shard key. Inserting documents into the target collection must have happened via an AQL query like FOR doc IN source INSERT doc INTO target. In this particular situation, the document keys (_key attribute) from the source collection were used as-is for insertion into the target collection. However, as the target collection is not sharded by _key and uses a custom shard key, it is actually not allowed to specify user-defined values for _key. Versions before 3.8 failed with the error “must not specify _key for this collection” when running such AQL query, but versions between 3.8.0 and 3.9.2 did not.
Affected Versions: 3.8.0 - 3.8.7, 3.9.0 - 3.9.2
Fixed in Versions: 3.8.8, 3.9.3
Reference: arangodb/arangodb#16764

Upgrading

Issue
Date Added: 2019-05-16 Component: arangod Deployment Mode: All Description: Bugfix release upgrades such as 3.4.4 to 3.4.5 may not create a backup of the database directory even if they should. Please create a copy manually before upgrading. Affected Versions: 3.4.x, 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x (Windows and Linux) Fixed in Versions: - Reference: arangodb/planning#3745 (internal)
Date Added: 2019-12-10 Component: Installer Deployment Mode: All Description: The NSIS installer for Windows may fail to upgrade an existing installation, e.g. from 3.4.a to 3.4.b (patch release), with the error message: “failed to detect whether we need to Upgrade” Affected Versions: 3.4.x, 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: arangodb/release-qa#183 (internal)
Date Added: 2020-01-07 Component: Installer Deployment Mode: All Description: The NSIS installer for Windows can fail to add the path to the ArangoDB binaries to the `PATH` environment variable, silently or with an error. Affected Versions: 3.4.x, 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: arangodb/release-qa#183 (internal)
Date Added: 2022-08-25 Component: arangod Deployment Mode: Cluster Description: If any collection in a 3.8.x cluster has a schema set, the following issue may occur after upgrading to 3.9.x: the server background maintenance tasks go into a busy loop. As no workaround currently exists, such an upgrade must not be performed. Affected Versions: 3.9.0 - 3.9.2 Fixed in Versions: 3.9.3

Hot Backup

Issue
Date Added: 2019-10-09 Component: Hot Backup API / arangobackup Deployment Mode: All Description: The Hot Backup feature is not supported in the Windows version of ArangoDB at this point in time. Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: N/A
Date Added: 2019-10-09 Component: Hot Backup API / arangobackup Deployment Mode: DC2DC Description: Hot Backup functionality in Datacenter-to-Datacenter Replication setups is experimental and may not work. Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: N/A
Date Added: 2019-10-09 Component: arangobackup Deployment Mode: All Description: The startup option `--operation` works as positional argument only, e.g. `arangobackup list`. The alternative syntax `arangobackup --operation list` is not accepted. Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: N/A

Schema Validation

Issue
Date Added: 2019-03-17 Component: Schema Validation Deployment Mode: All Description: The schema validation cannot pin-point which part of a rule made it fail. This is under investigation but very hard to solve for complex schemas. For example, when using `not` and `anyOf`, this would result in trees of possible errors. For now users should fall back to tools like jsonschemavalidator.net Affected Versions: 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: N/A
Date Added: 2019-03-17 Component: Schema Validation Deployment Mode: All Description: Remote schemas are not supported for security reasons. This limitation will likely remain unfixed. Affected Versions: 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: N/A
Date Added: 2019-06-25 Component: Schema Validation Deployment Mode: All Description: When using arangorestore for a collection with a defined schema, schema validation is not executed. Affected Versions: 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: N/A

Other

Issue
Date Added: 2019-05-16 Component: Starter Deployment Mode: All Description: The ArangoDB Starter falls back to the IP `[::1]` under macOS. If there is no entry `::1 localhost` in the `/etc/hosts` file or the option `--starter.disable-ipv6` is passed to the starter to use IPv4, then it will hang during startup. Affected Versions: 0.14.3 (macOS only) Fixed in Versions: - Reference: N/A
Date Added: 2019-05-24 Component: Web UI Deployment Mode: Active Failover Description: The web interface shows a wrong replication mode in the replication tab in Active Failover deployments sometimes. It may display Leader/Follower mode (the default value) because of timeouts if `/_api/cluster/endpoints` is requested too frequently. Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: N/A
Date Added: 2019-04-03 Component: arangod Deployment Mode: Cluster Description: Updating the properties of a collection in the cluster may return before the properties are updated consistently on all shards. This is especially visible when setting a schema for a collection with multiple shards, and then instantly starting to store non-conforming documents into the collection. These may be accepted until the properties change has been fully propagated to all shards. Affected Versions: 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: N/A
Date Added: 2021-04-07 Component: arangod Deployment Mode: All Description: The Batch API (HTTP endpoint `/_api/batch`) cannot be used in combination with Stream transactions to submit batched requests, because the required header `x-arango-trx-id` is not forwarded. It only processes `Content-Type` and `Content-Id`. Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: arangodb/arangodb#13552
Date Added: 2021-08-06 Component: Installer Deployment Mode: Single Server Description: The Windows installer fails during database initialization with the error `failed to locate tzdata` if there are non-ASCII characters in the destination path. Affected Versions: 3.8.x, 3.9.x Fixed in Versions: - Reference: BTS-531 (internal)
Date Added: 2022-01-31 Component: ArangoSync, SmartGraphs Deployment Mode: DC2DC Description: In a DC2DC replication scenario, when you try to replicate a Smartgraph using SatelliteCollections (for versions 3.9.x) or a Disjoint Smartgraph (for versions 3.8.x and earlier), the sync of collections may get stuck. Affected Versions: 3.7.x, 3.8.x, 3.9.x Fixed in Versions: 3.8.7, 3.9.2 Reference: BTS-737 (internal)
Date Added: 2022-02-08 Component: SmartGraphs Deployment Mode: Cluster Description: An error may occur during an attempt to alter a Disjoint SmartGraph using SatelliteCollections relation for a specific case when several relations of different configurations are present. Affected Versions: 3.9.x Fixed in Versions: 3.9.2 Reference: BTS-787 (internal)
Date Added: 2022-05-30 Component: ArangoSync Deployment Mode: DC2DC Description: In a DC2DC replication scenario, _users collection may fail to be replicated. Affected Versions: 3.8.x, 3.9.x Fixed in Versions: - Reference: BTS-854 (internal)
Date Added: 2022-09-29 Component: ArangoDB Starter Deployment Mode: All Description: The ArangoDB Starter may fail to pick a Docker container name from cgroups. Affected Versions: 3.8.x, 3.9.x Fixed in Versions: 3.9.9 Reference: GT-207 (internal)
Date Added: 2022-10-26 Component: ArangoSync Deployment Mode: DC2DC Description: When upgrading from 3.8.8 or to 3.8.8/3.9.4, the _analyzers collection cannot be replicated. Affected Versions: 3.8.8, 3.9.4 Fixed in Versions: 3.8.9, 3.9.6 Reference: BTS-1094 (internal)
Date Added: 2023-02-17 Component: ArangoDB Starter Deployment Mode: All Description: When using a Windows build with `netgo`, the `localhost` cannot be resolved. Affected Versions: 3.9.8 Fixed in Versions: 3.9.9 Reference: GT-330 (internal)

❮ What's New in 3.9 Incompatible changes in 3.9 ❯