[tae898]

Refs #267 (rows 10 and 11). Two pages in one PR, because the executor page and the durability page point at each other: how-to/durability.adoc (Durability settings) and how-to/async-executor.adoc (The async executor). Nav gets two lines, and one-sentence links go into concurrency.adoc, transactions.adoc and bulk-loads.adoc. quickstart.adoc is not touched.

Tests came first. tests/test_durability_behavior.py and tests/test_async_executor_behavior.py pin each sentence about Python behavior, and tests/test_docs_durability_page.py and tests/test_docs_async_page.py run every Python block of each page in order and compare the printed output, with the same helper pattern as the transactions and values pages. They use SQL and the executor getters, no Java object, so they run on both builds. Four tests read a thread's flush type from the Java database and are listed in conftest.NATIVE_NA_JVM_TESTS. Nothing was run locally (no pytest, java or docker for this slice): every block and test file was compiled, pyflakes, black, isort and bandit are clean, and CI is the first real run. Expect that a sentence I derived from the source can fail on one build.

The durability page states what a crash loses only as what the engine documents, because no test can lose power. Sources, all engine 26.11.1: GlobalConfiguration.java (TX_WAL_FLUSH, TX_WAL_GROUP_COMMIT, FILE_SYNC descriptions: process crash safe at level 0, power loss not; the group commit window; fileSync false skips every flush), WALFile.java lines 798 to 801 (force(false) at level 1, force(true) at level 2), ArcadeDBServer.java lines 650 to 665 (production mode sets level 1), TransactionContext.java and LocalDatabase.java (walFlushSetting is a field of the open database), GraphBatch.java (builder defaults useWAL=false, walFlush=NO; save and restore of the thread and async executor settings), DatabaseAsyncExecutorImpl.java lines 123 and 124 (executor defaults: WAL on, flush NO). The page gives no timing and recommends no default: the durability-wal timed study has not run and the maintainers decide defaults. It does not repeat the one-machine commit times that concurrency.adoc already has.

What the tests pin: set_wal_flush accepts the three lower-case names and refuses anything else with the list; it is not a stored setting; a closed database raises ArcadeDBError; schema:database reports arcadedb.txWalFlush (default 0) and arcadedb.txWalGroupCommit (default true); arcadedb.fileSync has JVM scope, is not in that list, and ALTER DATABASE refuses it; ALTER DATABASE stores the flush level and it survives a reopen; the executor's own flush stays no whatever set_wal_flush or ALTER DATABASE say; a GraphBatch relaxes the shared executor to use_wal=False and no (or to what you pass), puts the earlier settings back on close, also when the block raises, and leaves the flush of your own transactions alone (JVM). Executor: every db.async_executor() call wraps the one engine executor (settings are shared); close() shuts it down for every wrapper (a submit through a sibling raises with "shut down" in the text, and the sibling's is_closed() stays False); callbacks run on an engine thread; a failed statement without an error callback raises nowhere, stores nothing, and does not stop later statements; positional and named parameters together raise ValueError; four threads can submit to one executor.

Surprises and open questions, for the maintainers (nothing filed):

1. ALTER DATABASE on arcadedb.txWalFlush and the calling thread. TransactionContext.configuredWALFlush is a final field read in the constructor, so it is the value when the thread got its transaction context. The test pins only that a thread that starts after the statement commits with the stored level (JVM). Whether the thread that ran the statement follows it is not pinned and the page says so. The existing durability section of concurrency.adoc shows the statement with a read of the stored value only, which is also all the page claims. Worth one JVM probe: a second getTransaction().getWALFlush() on the same thread after ALTER DATABASE.
2. A submit after close() raises the engine's Java exception unwrapped on the JVM build (the async wrapper methods have no try), and a binding error on the native build. The page does not name the class and the test catches Exception. Probably wants one ArcadeDBError on both.
3. The wrappers of db.async_executor() keep separate state over one executor: is_closed() of a sibling stays False after another wrapper closed the engine executor.
4. Database.async_executor() after the engine executor was closed returns a wrapper over the same closed executor (LocalDatabase.async() keeps the field). Not tested and not claimed, because setParallelLevel recreates the worker threads and I could not run it.

CI so far: the JVM test workflow on the current head passes (24 of 24 jobs, including both docs-page tests). The native parity legs run now that the PR is ready, and they are the first run of the native-side expectations.

What remains of #267 after this: rows 1 (ResultSet), 4 (import and export), 5 (DataFrame, Arrow, columns), 6 (server mode), 7 (Cypher 26.11.1 vector features), 8 (functions and events, another agent), 12 (one line on the Schema API) and 13 (find_nearest_by_key), plus the wrong-or-stale list as far as #264 did not take it. Not covered on the pages I added: what a Python callback that raises does inside the executor, and the append_samples, scan_type, new_edge and new_edge_by_keys submits (docstrings only).

🤖 Generated with Claude Code