Known Issues in ArangoDB 3.6
Important issues affecting the 3.6.x versions of the ArangoDB suite of products
Note that this page does not list all open issues.
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 collectionAffected Versions: 3.5.x, 3.6.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 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 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 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 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, 3.6.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 |
---|
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 Fixed in Versions: - Reference: arangodb/arangodb#6399 |
Date Added: 2020-01-07 Component: AQL Deployment Mode: Cluster Description: It is not possible to execute AQL traversals in a cluster using collection sets (anonymous graph) for datasets where edges point to other edges. This is an uncommon use case, but it worked in previous versions. Affected Versions: 3.6.0 Fixed in Versions: 3.6.1 Reference: arangodb/arangodb#10801 |
Date Added: 2020-07-22 Component: AQL Deployment Mode: Cluster Description: When explicitly destroying an AQL Cursor created with stream: true in a cluster deployment, the server does not reply (the request hangs forever).Affected Versions: 3.6.x, 3.7.0 Fixed in Versions: 3.7.1 Reference: BTS-126 (internal) |
Date Added: 2021-04-19 Component: AQL Deployment Mode: All Description: User-defined variable names in AQL cannot start with an underscore, in contrast to what the AQL documentation claimed. Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x Fixed in Versions: 3.9.0 Reference: arangodb/arangodb#13513 |
Date Added: 2021-05-25 Component: AQL Deployment Mode: All Description: Global and per-query memory limits are not enforced for AQL graph traversals. Such queries may thus cause out-of-memory issues as they will not be killed despite exceeding the configured --query.memory-limit or Cursor API memoryLimit .Affected Versions: 3.5.x, 3.6.x, 3.7.x, 3.8.x, 3.9.x Fixed in Versions: - Reference: BTS-411 (internal) |
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 (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 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 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 |
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 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 Fixed in Versions: - Reference: N/A |
Date Added: 2021-08-06 Component: Coordinator Deployment Mode: Cluster Description: Restoring a hot backup to another deployment that has databases with the same names as in the backup can cause these databases to become inaccessible on Coordinators. They can be listed with db._databases() in arangosh, but not accessed using db._useDatabase() .Affected Versions: 3.6.x, 3.7.x, 3.8.x Fixed in Versions: 3.7.14, 3.8.1 Reference: BTS-527 (internal) |
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 Master/Slave mode (the default value) because of timeouts if /_api/cluster/endpoints is requested too frequently.Affected Versions: 3.5.x, 3.6.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, 3.6.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, 3.6.x Fixed in Versions: 3.4.10, 3.5.5, 3.6.1 Reference: arangodb/arangodb#10800 |
Date Added: 2020-04-23 Component: arangod Deployment Mode: Cluster Description: The creation of example graphs fails if --cluster.min-replication-factor is set to a value greater than 1, because the system attempts to create the collections with a replication factor of 1 despite the higher minimum.Affected Versions: 3.6.x Fixed in Versions: 3.6.4 Reference: arangodb/arangodb#11487 |
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 cannot be read, resulting in an early exit.Affected Versions: 3.4.x, 3.5.x, 3.6.x Fixed in Versions: 3.4.11, 3.5.6, 3.6.4 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-07-31 Component: Web UI Deployment Mode: All Description: The web interface confirms the creation of an index, but then displays an error 404: Not Found despite of a successful index creation.Affected Versions: 3.6.x, 3.7.x Fixed in Versions: 3.6.6, 3.7.1 Reference: arangodb/arangodb#12248 |
Date Added: 2020-08-12 Component: Web UI Deployment Mode: All Description: The web interface may show inconsistent results, such as an empty view for a collection with documents while displaying a document count higher than 0, if nginx or Cloudflare proxying with HTTP 2 is used. The Chrome developer console logs the following error when it occurs: Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR . Version 3.7.0 and above resolve the problem indirectly because of server-side support for the HTTP/2 protocol.Affected Versions: 3.6.x Fixed in Versions: 3.7.0 Reference: arangodb/arangodb#11636 |
Date Added: 2020-11-20 Component: arangod Deployment Mode: All Description: The value of the startup option --network.io-threads is clamped to 1 .Affected Versions: 3.6.x, 3.7.x Fixed in Versions: 3.6.10, 3.7.5 Reference: arangodb/arangodb#13051 |
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: 2020-12-10 Component: arangod Deployment Mode: Cluster Description: A database not found error may occur in a setup with multiple Coordinators when the list of slow queries is accessed or cleared directly after a new database has been created. Affected Versions: 3.6.10, 3.7.5 Fixed in Versions: 3.6.11, 3.7.6 Reference: arangodb/arangodb#13190 |
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 |
Date Added: 2021-04-19 Component: arangod Deployment Mode: Cluster Description: Deadlocks may occur with transactions that acquire exclusive transaction locks in cluster deployments (Stream Transactions and JavaScript transactions with { "collections": { "exclusive": […] } } , AQL queries with OPTIONS { exclusive: true } ). If two or more exclusive transactions touch data on different DB-Servers from one another, then they may get executed in parallel, thus being exclusive only at DB-Server level and not cluster-wide. Depending on what subsequent operations are performed, the transactions can potentially lock each other so that neither can make progress anymore. They will eventually expire due to idle timeout.Affected Versions: 3.6.x Fixed in Versions: 3.7.0 Reference: BTS-331 (internal) |
Date Added: 2021-07-20 Component: Replication Deployment Mode: Cluster Description: The synchronous replication protocol used in cluster deployments has a flaw that can cause follower shards to lag behind the leader shards for extended periods of time, without detecting that the synchronization is delayed. While uncommon to occur, it can lead to inconsistencies between replicas that may cause follow-up issues. It is important to upgrade 3.6.x deployments to at least 3.6.15 and 3.7.x deployments to 3.7.13 and to set and keep the supervision in maintenance mode during the whole upgrade process in case of manual cluster deployments. For ArangoDB Starter cluster deployments, make sure to use at least version 0.15.0-1 of the starter. In case of Kubernetes-operated clusters, make sure to use at least version 1.2.0 of kube-arangodb .Affected Versions: 3.6.x, 3.7.x Fixed in Versions: 3.6.15, 3.7.13 Reference: Technical Alert #6 |