Known Issues in ArangoDB 3.5

Known Issues in ArangoDB 3.5

This page lists important issues affecting the 3.5.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 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 Fixed in Versions: - Reference: arangodb/backlog#508 (internal)
Date Added: 2018-12-03 Component: ArangoSearch Deployment Mode: Cluster Description: ArangoSearch index consolidation does not work during creation of a link on existing collection which may lead to massive file descriptors consumption Affected Versions: 3.4.x, 3.5.x Fixed in Versions: 3.6.0 Reference: arangodb/backlog#509 (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 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 can not 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 Fixed in Versions: - Reference: N/A
Date Added: 2019-11-06 Component: ArangoSearch Deployment Mode: Cluster Description: There is a possibility to get into deadlocks during Coordinator execution if a custom Analyzer was created (and is present in the `_analyzers` system collection). It is recommended not to use custom Analyzers in production environments in affected versions. Affected Versions: 3.5.x Fixed in Versions: 3.5.3 Reference: arangodb/backlog#651 (internal)
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 Fixed in Versions: - Reference: arangodb/backlog#679 (internal)
Date Added: 2020-05-22 Component: ArangoSearch Deployment Mode: Cluster Description: The immediate recreation of ArangoSearch Analyzers in cluster deployments (deleting and shortly after creating one with the same name but different properties) causes errors in queries which involve such recreated Analyzers. For a workaround see Purge Analyzer cache below. Affected Versions: 3.5.x Fixed in Versions: - Reference: arangodb/backlog#669 (internal), arangodb/backlog#695 (internal)
Date Added: 2020-07-31 Component: ArangoSearch Deployment Mode: All Description: AQL queries with subqueries or joins in SEARCH expressions may return incorrect results. As a workaround, you can disable the optimizer rule which causes the problem with the following query options: `{ optimizer: { rules: [ “-inline-subqueries” ] } }` Affected Versions: 3.5.x, 3.6.x, 3.7.x Fixed in Versions: - Reference: arangodb/arangodb#12247

Purge Analyzer cache

To fix query errors caused by an immediately re-created Analyzer, the DB-Servers need to be forced to clear their Analyzer caches. This can be achieved by using below code in arangosh:

Connect to a Coordinator with arangosh
var analyzers = require("@arangodb/analyzers");
analyzers.remove("<PROBLEMATIC ANALYZER>");
var dummy = "dummy_analyzer_" + Date.now();
analyzers.save(dummy, "identity", {});
db._query("FOR d IN <ANY EXISTING VIEW> SEARCH ANALYZER(STARTS_WITH(d.test, 'something'), @a) RETURN d", {a: dummy});

This query with a new Analyzer will force cache purging. If this query reports an error about a missing Analyzer, then wait for a minute and retry until it succeeds.
Re-create your Analyzer (<PROBLEMATIC ANALYZER>) with the new, correct properties.
analyzers.remove(dummy);
Check if the original query still fails. It is possible that it reports a missing Analyzer, but the problem should go away in a minute and the query execute normally.

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 Fixed in Versions: - Reference: arangodb/arangodb#6399

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
Fixed in Versions: -
Reference: arangodb/arangodb#6399

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 (Windows and Linux) Fixed in Versions: - Reference: arangodb/planning#3745 (internal)
Date Added: 2019-11-06 Component: arangod Deployment Mode: All Description: Upgrades from ArangoDB version 3.4.x to 3.5.0 or 3.5.1 don’t create the `_analyzers` system collection, preventing creation and use of custom Analyzers. Suggested workaround: Create the missing collection manually in each database of an ArangoDB deployment after upgrade (arangosh example: `db._create(“_analyzers”, {isSystem: true})`) Affected Versions: 3.5.0, 3.5.1 Fixed in Versions: 3.5.2 Reference: arangodb/backlog#652 (internal)
Date Added: 2019-11-06 Component: arangod Deployment Mode: Cluster Description: Rolling cluster upgrades from ArangoDB version 3.5.0 to 3.5.1 are not possible due to errors at DBServer nodes. A fix is contained from version 3.5.2 on, and rolling upgrades to this version are possible. Affected Versions: 3.5.0, 3.5.1 Fixed in Versions: 3.5.2 Reference: arangodb/backlog#652 (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 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 Fixed in Versions: - Reference: arangodb/release-qa#183 (internal)
Date Added: 2020-12-18 Component: Agency Deployment Mode: Cluster Description: When upgrading a cluster from 3.5.x to 3.6.10, the upgrade can get stuck. Please update to 3.5.7 first before you upgrade to 3.6.10. If you are already in this situation, then you need to kill the stuck Agent. In a Kubernetes environment, use `kubectl` to get a list of all ArangoDB pods. You should see that one of the Agent pods has not yet restarted. Check the log file for a line like `control-c received` near the end, followed by no or only a few more log lines. Kill this pod with `kubectl`. Affected Versions: 3.5.x, 3.6.10 Fixed in Versions: 3.5.7 Reference: N/A

Stream Transactions

Issue
Date Added: 2019-08-19 Component: Transactions Deployment Mode: All Description: Stream Transactions do not honor the limits described in the documentation. Currently the idle timeout of 10 seconds will not be enforced, neither will the maximum size of transaction be enforced. Affected Versions: 3.5.0 Fixed in Versions: 3.5.1 Reference: arangodb/arangodb#9775
Date Added: 2019-08-19 Component: Transactions Deployment Mode: All Description: Stream Transactions do not support the graph operations that are initiated via the `general-graph` / `smart-graph` JavaScript module or via the REST API at `/_api/gharial`. These operations will act as if no stream transaction is present. Affected Versions: 3.5.0 Fixed in Versions: 3.5.1 Reference: arangodb/arangodb#9855 / arangodb/arangodb#9911
Date Added: 2019-08-19 Component: Transactions Deployment Mode: All Description: Stream Transactions do not support user restrictions. Any authenticated user may access any ongoing transaction so long as they have access to the database in question. Affected Versions: 3.5.0 Fixed in Versions: 3.5.1 Reference: arangodb/arangodb#9796

Hot Backup

Issue
Date Added: 2019-10-09 Component: Hot Backup API / arangobackup Deployment Mode: All Description: ArangoSearch Views are not backed up and thus not restored yet. Therefore, Views have to be dropped and recreated after a restore. This happens automatically in the background, but in particular in the presence of large amounts of data, the recreation of the ArangoSearch indexes can take some time after the restore. It is planned to rectify this limitation in one of the next releases. Note furthermore that a running query with views can prevent a restore operation from happening whilst the query is running. Affected Versions: 3.5.x Fixed in Versions: 3.6.0 Reference: N/A
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 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 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 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-16 Component: arangod Deployment Mode: All Description: Calling a shutdown endpoint may not result in a proper shutdown while the node/server is still under load. The server processes must be ended manually. In v3.5.1 and later, two different issues are fixed: libgcc/libmusl wrongly detecting multi-threadedness in statically linked executables and a read/write lock race condition. Affected Versions: 3.5.0 Fixed in Versions: 3.5.1 Reference: v3.5.1 CHANGELOG / Blog Post “When Exceptions Collide”
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 Master/Slave mode (the default value) because of timeouts if `/_api/cluster/endpoints` is requested too frequently. Affected Versions: 3.5.x Fixed in Versions: - Reference: N/A
Date Added: 2019-09-11 Component: Indexing Deployment Mode: All Description: A time to live (TTL) index does not remove documents from a collection if the path points to a nested attribute. Only top-level attributes work. Affected Versions: 3.5.x Fixed in Versions: - Reference: N/A
Date Added: 2019-12-10 Component: Installer Deployment Mode: All Description: The DMG package for macOS is not notarized, which prevents the execution of ArangoDB3-CLI.app under macOS 10.15 (Catalina) with error message: “ArangoDB3-CLI can’t be opened because Apple cannot check it for malicious software” Affected Versions: 3.3.x, 3.4.x, 3.5.x Fixed in Versions: 3.4.10, 3.5.5, 3.6.1 Reference: arangodb/arangodb#10561
Date Added: 2020-01-07 Component: Installer Deployment Mode: All Description: V8-based binaries of the client packages (arangosh, arangoinspect, foxx-manager) have an incorrect default value for `javascript.startup-directory` and will thus not find the required JavaScript folder unless specified by the user. Affected Versions: 3.4.x, 3.5.x, 3.6.0 Fixed in Versions: 3.4.9, 3.5.4, 3.6.1 Reference: arangodb/release-qa#183 (internal)
Date Added: 2020-01-07 Component: Installer Deployment Mode: All Description: The client packages for Windows miss the arangoinspect binary. As a workaround, you can run arangosh with the following options: `arangosh —server.authentication false —server.ask-jwt-secret —javascript.client-module inspector.js …` Affected Versions: 3.3.x, 3.4.x, 3.5.x, 3.6.0 Fixed in Versions: 3.3.25, 3.4.10, 3.5.5, 3.6.1 Reference: arangodb/arangodb#10835
Date Added: 2020-01-07 Component: Foxx Deployment Mode: Cluster Description: In case of a Foxxmaster failover, jobs in state `‘progress’` are not reset to `‘pending’` to restart execution. Affected Versions: 3.4.x, 3.5.x Fixed in Versions: 3.4.10, 3.5.5, 3.6.1 Reference: arangodb/arangodb#10800
Date Added: 2020-05-18 Component: all arangod / arangosh based programs & tools Deployment Mode: All Description: When using the `—config` option to set the configuration file location the ArangoDB C++ binaries check for `<filename>.local` among other paths. If this path happens to be a directory then the expected configuration can not be read, resulting in an early exit. Affected Versions: 3.4.x, 3.5.x Fixed in Versions: 3.4.11, 3.5.6 Reference: arangodb/arangodb#11632
Date Added: 2020-06-19 Component: SmartGraphs Deployment Mode: Cluster Description: When inserting edges into an edge collection of a SmartGraph, the auto-generated `_rev` values for the ingoing and outgoing part of the edge may differ. This can be confusing when querying the `_rev` values of the edges later. Affected Versions: 3.4.x, 3.5.x, 3.6.x, 3.7.x Fixed in Versions: 3.6.5, 3.7.1 Reference: N/A
Date Added: 2020-06-30 Component: SmartGraphs Deployment Mode: Cluster Description: Changing the collection properties of a smart edge collection did not propagate the changes to child collections for the `waitForSync`, `cacheEnabled` and `schema` attributes. This has been fixed in 3.7.1 for new smart edge collections, created with 3.7.1 or later. Affected Versions: 3.4.x, 3.5.x, 3.6.x, 3.7.x Fixed in Versions: 3.7.1 Reference: arangodb/arangodb#12065
Date Added: 2020-07-31 Component: Web UI Deployment Mode: All Description: The API tab of Foxx services does not render the Swagger UI interface. Affected Versions: 3.5.x, 3.6.x, 3.7.x Fixed in Versions: 3.5.6, 3.6.6, 3.7.1 Reference: arangodb/arangodb#12297
Date Added: 2020-11-20 Component: arangod Deployment Mode: All Description: The `Www-Authenticate` header is not set for HTTP 401 responses as required by the HTTP specification, despite the documentation claiming this behavior. Affected Versions: 3.5.x, 3.6.x, 3.7.x Fixed in Versions: 3.8.0 Reference: arangodb/arangodb#13001
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 Fixed in Versions: - Reference: arangodb/arangodb#13552

Known Issues in 3.5