Changelog¶

v7.26.4 (2026-10-05)¶

The tests and their tooling, after four rounds of cloud verification of the suite’s speed work (REV-CLOUD.md). One real defect fixed: 18 tests linked the kernel archives by a bare name and ran on the old library after a change of the one they test. No change in the libraries or in the yunos, so a node running 7.26.x needs no upgrade. The suite passes in parallel on the dev machine (298/298, ctest -j8) and on wattyzer (298/298, -j8). The yunetas CLI goes with it: 0.21.2.

• The tests that assert a time window of the wall clock run alone under ctest -j (RUN_SERIAL): test_yevent_timer_once1, _once2, _periodic1, _kept_after_post, test_c_timer, test_c_timer0, test_static_resolv_numeric. test_yevent_timer_once1 failed once in the cloud verification’s parallel suite (1.80 s, window 0.9-1.1 s). And timeranger2/test_fs_watcher_overflow, which asserts the watcher’s cost per directory on a big tree against a small one (at most 6 times): wattyzer’s parallel suite (-j8, load ~4) failed it with 48 us against 713; it passes alone in 31 s. And test_c_controlcenter_scenarios, whose rate of a burst over its 1.5 s tick fails when the load stretches the tick over 50% (the last test of that class, by the fifth check of REV-CLOUD.md).

• scripts/check_test_databases.py no longer erases why a test failed. ctest truncates Testing/Temporary/LastTest.log on every run, its --show-only too: the check keeps the file and puts it back. And the CLI 0.21.2 runs ctest with --output-on-failure, so the output of a failed test is in the kept build/<date>.j<N>.txt as well.

• scripts/check_md_fences.py: a fenced block whose closing fence has text glued after it does not close, and the rest of the page renders as code; docs/doc.yuneta.io/deploy.sh refuses to build such a page. It happened in test_suite.md (fixed). check_test_links.py reports by line.

• 18 tests are relinked again when a kernel library changes. The 14 tr_treedb_* tests, tr_dt_unknown, perf_timeranger2, perf_tr_treedb and perf_rotatory named libtimeranger2.a, libyev_loop.a, libytls.a and libyunetas-gobj.a bare in target_link_libraries(): a -l search, not a dependency of the link. After a change in timeranger2 or gobj -- what they test -- they ran on the OLD library, silently. The make clean of yunetas test hid it, and then (7.26.1-7.26.2) the reinstall of the root tree. They name them ${LIB_DEST_DIR}/lib*.a now: a marker appended to gobj.c reaches every test binary that holds gobj code (286), where it reached 268. Found by the cloud verification of REV-CLOUD.md. scripts/check_test_links.py fails on an archive named bare in a CMakeLists.txt of tests/c, performance/c or stress/c.

• scripts/check_test_databases.py: two tests that can use one directory at the same time are found, as check_test_ports.py finds two that use one port. It reads the directories of each test from its sources (also the "database" key of a C_NODE/C_TREEDB kw, a build_path() segment after path_root, and the domain of register_yuneta_environment()) and its RESOURCE_LOCK / RUN_SERIAL / DEPENDS / fixtures from ctest, and exits 1 when two tests name one directory (or one under the other) and ctest can run them at once. The tree passes it today: 185 directories, the four shared ones each under a lock.

• timeranger2/test_tr2check runs the tr2check of its own checkout (utils/c/tr2check/build/tr2check), not /yuneta/bin/tr2check: that one is machine-wide, the last one installed, and a run from a worktree (the A/B against the last tag, a node’s release suite) tested somebody else’s. A missing tool fails as “tr2check not found at ”, not as a tool that answered no json.

• scripts/check_test_links.py reads every CMakeLists.txt of tests, performance, stress, yunos, utils and modules, comments left out: a lib*.a without a directory anywhere (also in a set()), and -lfoo or a bare foo in target_link_libraries() when libfoo.a is an archive of outputs/lib or outputs_ext/lib. It fails when a directory cannot be read, and says how many files it checked. It found two more: pkey_to_jwks (libssl.a, libcrypto.a, now ${EXT_LIB_DIR}/...) and dba_postgres (libyunetas-c_postgres.a, a name no build makes, now ${MODULE_POSTGRES}). The release checklist runs the three checks of the tests before a tag.

• perf_c_tcp/test4 and perf_c_tcps/test4 no longer hold the perf_topic_integer lock, which only test5 needs (both stay RUN_SERIAL). tests/c/README.md and performance/c/README.md say what a new test must declare to run in parallel, and the three checks.

• The yunetas CLI 0.21.1: yunetas test runs ctest in parallel from SDK 7.26.3 on (not 7.26.1), yunetas build takes --jobs, and the ctest log is build/<date>.j<N>.txt, so serial and parallel timings are not mixed.

v7.26.3 (2026-10-05)¶

A fix of the test suite: 7.26.2’s suite failed on two nodes running it in parallel (hidraulia, artgins), because the groups of test_c_treedb_literal_wins exhausted the per-user inotify instances. No change in the libraries or in the yunos, so a node running 7.26.0 to 7.26.2 needs no upgrade.

• test_c_treedb_literal_wins releases its inotify instances as it goes. A sweep (CR, O4C/O4A/O4X, FP) and the 41 scenarios of the group early ran in ONE step of the loop. The watcher of a treedb that closes releases its inotify instance only when the loop completes its cancel, so a group held up to ~1900 instances. Since 7.26.2 runs the groups at once, they reached the per-user limit of 4096: on hidraulia ctest -j12 failed emailsender/late_server, test_fs_watcher_overflow and the group early with “inotify_init1() FAILED: The user limit on the total number of INOTIFY INSTANCES has been reached”. Each step now runs one scenario or one iteration, and the steps are 10 ms apart, as the test asked: C_TIMER0 instead of C_TIMER, whose steps ran on the yuno’s 1 s tick. The largest group now holds ~290 instances, and the whole suite peaks at ~700 instead of ~3860. The groups at once still take ~34 s. The whole suite in parallel then passed on hidraulia (298/298, 164 s) and artgins (298/298, 534 s).

v7.26.2 (2026-10-05)¶

A second release of the test suite and its build: no change in the libraries or in the yunos, so a node running 7.26.0 or 7.26.1 needs no upgrade. On the dev machine (8 cores), yunetas test with no change in the sources takes 226 s in all, against 470 s at 7.26.1 and ~31 minutes before 7.26.1. A machine with a root build/ from an earlier release stops building the SDK in it at its next build of that tree (the changed CMakeLists.txt re-runs its configure).

• The root build/ tree builds the tests, not the SDK (ENABLE_SDK, OFF by default). The kernel, modules, utils and yunos are built and installed by each module’s own build dir (yunetas build, and the first step of yunetas test). The root tree built them too, and installed a second copy of every library into outputs/lib over the first. Each tree replaced the other’s copy, and the new mtime relinked every executable of the other tree on every run, with nothing changed. Now a second yunetas test with no change relinks nothing (its root build: 1 s), and a changed library still relinks every test that links it by its full path. (Corrected after 7.26.3: 18 tests named the kernel archives bare and were not relinked; the reinstall of the root tree had hidden it.) -DENABLE_SDK=ON gives the old self-contained tree (the ASan recipe of test_suite.md uses it).

• test_c_treedb_literal_wins is seven tests, one per group of scenarios (test_c_treedb_literal_wins/early, /late1, /late2, /dcd, /dcn, /o4, /o4xa; DC is split into its sweep with drafts and its sweep without, O4X into the literal that changes and the one that adds), each in a store of its own (~/tests_yuneta/c_treedb_literal_wins_<group>). In one binary, the whole run took ~215 s and was the floor of a parallel suite. The seven run at the same time in ~34 s (8 cores). The binary takes --group=<name>; with no --group, it runs every scenario as before.

• A child of test_c_treedb_literal_wins retries its io_uring ring on ENOMEM/EAGAIN, as yev_loop_create() does (5 attempts, 100 ms doubling). With its groups running at once under ctest -j, a child of the DC sweep got io_uring_queue_init(4096) FAILED: Cannot allocate memory with memlock unlimited (a transient failure of the kernel to allocate the ring), and the sweep failed. In three rounds of the treedb/timeranger2 tests at -j8 afterwards, 4 retries, all recovered.

v7.26.1 (2026-10-04)¶

A release of the test suite and its tools: no change in the libraries or in the yunos, so a node running 7.26.0 needs no upgrade. yunetas test (CLI 0.21.0) compiles with make -j and no make clean, and runs ctest in parallel from this SDK on. On the review’s 4-core machine, a run with no change in the sources went from ~31 minutes to ~7-8.

• The tests declare what they share, so ctest -j runs the suite. The tests that use one directory under ~/tests_yuneta take a ctest RESOURCE_LOCK (tr_topic_pkey_integer, tr_msg, tr_delete_instance, perf_topic_integer; inotify_flood for the two tests that flood the inotify queue). test_topic_pkey_integer is the FIXTURES_SETUP of its six iterators, so ctest -R iterator3 alone passes now (before, it failed without the data). The benchmarks and that chain are RUN_SERIAL, so the times that the release trend reads stay alone. perf_yev_ping_pong2 writes ~/tests_yuneta/perf_yev_ping_pong2; before, it wiped the iterators’ database. Before this change, ctest -j4 failed five iterators; now the suite passes 292/292. The yunetas CLI 0.21.0 runs ctest in parallel only on an SDK that carries this change.

• test_fs_watcher_overflow allows the big tree to cost six times the small one per directory, not two. On a machine with a small L3 cache (artgins, 6 MiB), the 4096 directories of the small pass stay in the cache and the 69632 of the big pass do not. The test failed one run in three there, with correct code. The regression that the test guards against (the index rebuilt per slice) was 14 times.

• gobj-ui and yunos-js submodules: vite ^8.3.2 and maplibre-gl 6.12.0 (gobj-ui: devDependency only, no release; gui_agent 0.29.12, gui_treedb 0.17.78).

v7.26.0 (2026-10-04)¶

What changed after 7.25.22: five changes an operator or a developer has to know about (each in the upgrade steps below) -- a key delete signalled to the rt_disk followers with the master’s sequence (a protocol change between master and followers), with_link_events on by default, the tm markers of timeranger2 removed (an API removal), write-attr limited to SDF_WR attributes, and a negative t/tm bound that selects rows again -- the md2 rows read in blocks and the match condition parsed once per scan, and the defects of five reviews and of TODO.md, each with a test that fails on the code before it unless the entry says otherwise.

Performance, against 7.25.22¶

Measured against 7.25.22, each release built from its own tree, the two run alternately (8 rounds, 24 for the timeranger2 tests); the report is performance/reports/7.26.0.html. Reading a timeranger2 history is 16-17% faster (184,338 -> 215,157 records/s; page by page 166,017 -> 192,697), opening a treedb 20% faster (390 -> 311 us per node), a replica opens 12.6% faster (108.4 -> 94.8 ms, no tm marker looked for), and a tm query of one minute of a key on a topic 7.25.22 had NOT marked takes 12.8 ms instead of 402 (31x): the md2 rows read in blocks of 1024 and the match condition parsed once per scan. The prices, each with its reason: the same query on a topic 7.25.22 HAD marked takes 12.8 ms instead of 7.5 (+70%: no tm markers, every row read). Found by this A/B and fixed before the tag: a master that opened a topic wrote its delete_seq.json durably, which doubled the creation of topics and made the first open of 40 treedbs 55% longer; written not durably now (it holds 0), both are back within the noise of 7.25.22 (134 ms for 10 topics, 10.3 s for the 40 treedbs). Not measured: a key delete on a topic with an rt_disk feed, which by construction writes the record of its sequence first. Everything else within its noise.

Upgrade steps (operators, read first)¶

• Master and followers of a timeranger2 topic upgrade together (key delete signals, below). A follower of 7.25.22 under a 7.26 master takes each .d<seq>.<key> signal for a key: its key_deleted callback gets a key that does not exist, and the real delete is not heard. A 7.26 follower under a 7.25.22 master hears no delete at all, and says so when it opens a feed (“The master of the topic does not signal key deletes as this follower hears them”: there is no <topic>/delete_seq.json, which a 7.26 master makes when it opens the topic). Stop the followers (rt_disk readers: replica yunos, tr2list --follow, C_TRANGER lists of a non-master) before the master, and start them after it.

• with_link_events is on by default (C_NODE, C_TREEDB, C_AUTHZ): a link publishes EV_TREEDB_NODE_LINKED / UNLINKED, not the parent’s EV_TREEDB_NODE_UPDATED. A yuno served by a v1 SPA sets it 0 in its C_TREEDB and in its C_AUTHZ’s kw (estadodelaire and hidraulia do, in db_history); a gobj that subscribes to every event of a treedb service declares the two events or subscribes only what it handles; a GUI that shows a parent’s hooks needs gobj-ui 7.25.26 or later.

• write-attr writes only SDF_WR attributes. A script that set a persistent attribute without SDF_WR (max_sessions_per_user, allowed_ips, emailsender’s url, ...) uses the config or the attribute’s own command.

• tranger2_mark_tm_order() and C_TRANGER’s mark-tm-order are removed. Nothing to run on upgrade. A rollback to 7.25.5..7.25.22 runs that release’s mark-tm-order all=1 on every topic it marks, or a tm query can miss rows.

• A negative from_t / to_t / from_tm / to_tm selects rows again (it matched none since v7): a db_history started with from_t=-86400 now reads the last day at its start -- expect that load.

• fix: jtree without rename_hook gave every child twice. The hook kept the refs of the collapsed view ({id, topic_name}) and the children were appended after them, whole: [dev, ops, dev{...}, ops{...}]. The hook now starts empty and holds each child once, whole, as rename_hook already did. Nothing in the SDK, the projects or the SPAs called it without rename_hook. In 7.25.22 (from the port before v7). test_c_node_commands (red on the previous code: dev ops dev ops).

• tests, emailsender: what the sender rules and skip-email do, and a window that measured the test. New skip_paused (skip-email works with the service paused), default_from_case (a from that is the default in other letters IS the default: a not-found refusal is the account’s) and foreign_access_denied (a 5.1.8 that is no not-found is the account’s, whatever the from). url_change_resets_pacing was widened to 1.8 s without finding why the session connected 1 s late: it did not -- it connects in 1-2 ms; the fake server told the test on its C_TIMER, which is accurate to the second. With notify_delay 0 it tells at the connection itself, and the window is 800 ms -- under the 1 s of timeout_retry, with room for a loaded machine (red without reset_pacing(): 7 s).

• tests: test_fs_watcher_overflow measures the watcher against itself. It failed on artgins (a Xeon D-1521) with the code right: 224 us per directory against a fixed 200. Most of it was the test’s own: its loop counted the names told by walking all 69632 of them on every turn, and billed that to the watcher (73 us per directory here; 20 without it). The watcher’s cost on a tree of 69632 directories is now held against the same pass over 4096 on the same machine: at most twice, plus 20 us (14 and 20 us here; with the index of 7.25.10 rebuilt per slice, 31 and 437: red).

• tests: red tests for fixes that had none. deactivate-snap answering -1 when its save fails (test_tr_treedb_failed_save, the writes of the snap’s key failed by --wrap=write); save_json_to_file() answering -1 on a failed close() (test_helpers, --wrap=close); a kw that carries a gbuffer through C_NODE’s treedbs / links / hooks / node (test_c_node_commands) and C_MQIOGATE’s view-channels (test_c_qiogate_stats); kw_update_missing() with a gbuffer (test_command_binary_kw); and the templates of yuno-skeleton, built and run (yuno_skeleton/templates: a template timer that is a plain child never reaches ac_timeout, MSGSET_INTERNAL_ERROR does not compile; it tests the tree it is in, never /yuneta/development/yunetas or the installed yuno-skeleton). Each one red on the code before its fix (checked by putting that code back), green now.

• fix: C_NODE parents / children with no options logged an ERROR per option. The options are optional, and were read off a NULL: six ERRORs with a stack (“kw must be list or dict”) for each parents, one for each children. They are an empty dict now, as nodes already did. New test_c_node_commands: what the read commands of C_NODE answer (treedb-info, node, instances, pkey2s, jtree, parents, children, hooks, links, print-tranger) and what the snaps do to the data (red on the previous code: 18 unexpected ERRORs).

• BREAKING (protocol between master and followers): a key delete is signalled with the master’s delete sequence. tranger2_delete_key() removes the feed’s disks/<rt_id>/<key>/ as before, and then makes and removes disks/<rt_id>/.d<seq>.<key> in the directory of every feed (.h<seq>.<sha256> for a key longer than NAME_MAX - 23 bytes); seq is the topic’s delete sequence, recorded in <topic>/delete_seq.json (durable, before the signal) and growing across restarts of the master. A follower keeps, per key, the highest sequence it applied: a signal above it is a new delete (the key is forgotten), one at or below it a delete another feed heard first (the feed is told, nothing forgotten). It replaces the matching of a delete by its place in each feed’s queue (debts, doubts, the place each feed was watched from), which left two holes: a SECOND delete of a key heard first by a feed opened while the first one was in flight was taken for the first, and a feed opened AFTER another one heard a delete took its signal for a new one -- the key forgotten again (a key written again meanwhile went with it) and, in both, the delete told twice to a feed at its next overflow ([DEL DEL]). Both existed in 7.25.22. The master takes a delete’s sequence BEFORE the key leaves keys/, and a follower at an overflow lists keys/ and reads the sequence AFTER, so every key it finds missing is bounded at or above its delete: the keys told then are noted, and a signal of theirs queued behind the overflow is not told again; a delete not told there (of a key on disk again, or that no feed had heard) is told by its signal. What every feed heard is pruned, so the follower keeps no more than the deletes some feed may still hear. The master makes delete_seq.json (0) when it opens a topic that has none -- not durably: it holds 0, and one lost to a power cut (or left empty by it) is made again at the next open, while every number above 0 is written durably; a record it cannot read, or cannot WRITE, refuses the key delete (logged) before anything is removed and is left as it is (written late, a follower that read it in between would bound the key one below its delete), and a sequence taken for a delete that could not remove its key stays taken -- a gap, which the followers do not mind (given back, a follower that read it at an overflow would take the next delete for one it was told). A follower that hears a signal below its last one logs that the sequence went back; one that opens a feed on a topic with no record logs an ERROR, and an info when the feed hears its first signal after all. A signal the master made and could not remove (it died in between, or the rmdir() failed) is removed at its next open of the topic: the feed hears it then if it was the last delete; an older one, followed by deletes the feed heard, is moved out of the feed’s directory and removed unheard, said (told late, it could take a key written again out of the cache), and so is every leftover while the record cannot be read. Upgrade master and followers of a topic together (see the upgrade steps). The delete of a topic with rt_disk feeds costs two disk flushes more (the record of the sequence); a topic with none, nothing. The hashed form is chosen by the key’s LENGTH and kept apart from every key (no key holds a /), so a key starting with # is a key, and #<sha256 of a long key> never stands for that long key; the follower keeps the key a hash named while the delete is kept, so every feed is told it, not only the first one. test_delete_key_propagation: opened_after_heard and second_delete_in_doubt (red on the previous code: [DEL DEL] after the overflow), odd_keys (a # key, a key too long for the name, and #<its hash>, heard by two feeds: each delete forgets its own key, and each feed is told the three), delete_seq_record (the record made at the open, read from inside the rmdir() of the key to show it was written BEFORE the key left keys/, kept taken by a delete whose rmrdir() fails (never given back), a record that cannot be written or read refusing the delete, a left signal heard at the master’s next open and an older one removed unheard, a follower with no record saying so); the white-box checks of the old debts became “nothing of the deletes kept once every feed heard them” (in test_rt_disk_overflow: nothing kept below what every feed heard), and stale_debt_reborn (a debt put there by hand) went with the debts.

• BREAKING (default): with_link_events is ON by default -- in C_NODE, in C_TREEDB (copied to every treedb it opens) and in C_AUTHZ, which gets the attribute (new) and copies it to treedb_authzs. A link or an unlink now publishes EV_TREEDB_NODE_LINKED / UNLINKED (the relationship: hook_name, parent_topic_name, parent_id, child_topic_name, child_id) and NOT the parent’s EV_TREEDB_NODE_UPDATED; the child’s own update, from its save, is published as before. Why: the parent’s update is the parent collapsed whole -- every hook list, every child id -- on every link, whether anybody listens or not, so filing a child under a parent with thousands of children cost O(children), and a fleet of N new devices O(N²) at the moment it comes on line (measured in a stress test: ~70 ms of cpu per link, 3000 -> ~13 new devices/s). What to do:

  • A yuno served by a v1 SPA (it reads the parent’s update) sets it off: "with_link_events", 0 where it creates its C_TREEDB, and 'kw': {'with_link_events': false} in its C_AUTHZ when the SPA edits treedb_authzs (estadodelaire and hidraulia do, in db_history).

  • A gobj that subscribes to EVERY event of a treedb service, or the parent of a C_NODE hosted as a pure child (subscribed to everything), now receives the two events, and an FSM that does not declare them answers “Event NOT DEFINED in state”. Subscribe the events handled, or declare the two. C_MQTT_BROKER now subscribes only EV_TREEDB_NODE_CREATED/UPDATED/DELETED of its treedb (wattyzer’s db_history_wz the same).

  • A GUI that shows the parent’s hooks needs gobj-ui 7.25.26 (C_YUI_TREEDB_TOPICS re-reads the parent on a link event; the graph already followed them): gui_agent 0.29.10, gui_treedb 0.17.76. The next gobj-ui re-reads a parent only when its row is loaded, one read at a time per parent: a burst of links to it costs two reads per viewer, not one per link; and a re-read that fails (a parent deleted meanwhile) is a warning, never the app’s error modal. set-link-events still switches an open treedb at run time, and the configured value comes back at the next start. test_c_node_link_events creates its C_NODE without the attribute.

• timeranger2: a scan parses its match condition once, not per row. The matcher read match_cond with ~15 json_object_get() per row, the scan 3 more from the segment and 1 for its direction, and it wrote its position into the iterator (two json integers) per row. A scan now parses the condition into a C struct when it starts -- after get_segments(), which resolves a negative t/tm bound and writes it back, and never kept from one scan to the next -- reads a segment’s rows, file and t order once per segment, and writes its position once, when it ends (nothing reads it during the scan). A tm query of one minute on 1 key x 30 files x 20 000 rows (perf_timeranger2, 8 rounds alternated): 0.152 +- 0.003 s -> 0.0145 +- 0.001 s. The open phase is unchanged (it does not go through the matcher).

• timeranger2: the scans read md2 rows in blocks. An iterator’s load, its index, its pages and a follower’s new rows made an lseek() and a read() per 32-byte md2 row; they read 1024 rows with one pread() (a block never reaches past the rows the scan’s segment counts, so a file the master appends to is not read half way, and it is read again after any write of md2 rows by the process, so a user_flag rewritten from a callback is seen). A tm query of one minute on 1 key x 30 files x 20 000 rows (perf_timeranger2, 8 rounds alternated): 0.439 +- 0.071 s -> 0.168 +- 0.047 s. The rest is the per-row json of the matcher. One difference: a follower’s scan sees a user_flag the master rewrote in place DURING that scan up to a block later than it did (no ordering was promised between the two processes either way). test_tm_order: ranges across the block boundaries, both ways, on the three read roads, and a key of 2600 rows read whole.

• Schema editor (gobj-ui 7.25.25, gui_agent 0.29.9): a column with data behind it is warned about before it is deleted. The records keep the values of a deleted column and no reader shows them any more; the editor reads the topic (paged, capped) up to the first record holding a value and says so, or that it could not read them. Not refused: a decision.

• BREAKING (API removal): timeranger2’s tm markers are gone. From 7.25.5 the master marked an md2 file whose __tm__ went back (<file>.tm_unordered, and "marks_tm_unordered": true in a new topic’s topic_desc.json), and a tm query trusted the tm range of the files not marked: it skipped files out of the range and ended a file’s scan at its first row past it. tm is the producer’s time and the store keeps the records as they came, so ordering by it is not the store’s job: a from_tm / to_tm condition is now a FILTER on every row of the key, leaving no file out and ending no scan -- correct always, rollback-proof. Removed: tranger2_mark_tm_order() (public API) and the mark-tm-order command of C_TRANGER; nothing writes or reads .tm_unordered or marks_tm_unordered, and a store that has them keeps them, ignored (no migration). Cost: a tm query reads every md2 row of the key -- one minute on 1 key x 30 files x 20 000 rows takes ~12.8 ms with this release’s block reads and once-parsed condition (below), where a topic marked by 7.25.5..7.25.22 took 7.5 ms and an unmarked one ~0.40 s; who needs fast access by tm keeps it themselves (a topic keyed by it, an index in memory). The fr_tm / to_tm of a file in list-keys are its first and last rows unless the file was read whole: approximate when its tm goes back. The t marker (<file>.unordered, a late __t__) stays. Upgrade: nothing to run. Rollback to 7.25.5..7.25.22: run that release’s mark-tm-order all=1, or a topic that says it marks can miss rows in a tm query.

• A yuno keeps the case of its directory. register_yuneta_environment() lowercased the root_dir and domain_dir it was given, silently, while the agent builds a yuno’s directory as its realm and role are written and keeps its bin/ there: a capital in a realm’s owner, name, role or env, or in a yuno’s role or id, gave the yuno a sibling directory for its logs, data and temp/ that the agent’s commands never looked in. They are kept as given. No node had a capital under /yuneta/realms (checked 2026-10-03), so no directory was split.

• fix: C_NODE leaked the binary field of a record kw it shared with others. The treedb takes the gbuffer of the record it writes (treedb_store_files() removes the key and decrefs it once, because the treedb releases a record with json_decref()), and C_NODE handed it the caller’s kw itself. A kw shared by kw_incref() -- an event’s, held by every layer that published it -- lost the key under the other holders, whose kw_decref() then released nothing: one gbuffer per holder. The MQTT broker writes its session from the EV_ON_OPEN of the CONNECT, so every CONNECT with a will leaked its payload (~360 bytes), and so did every retained PUBLISH with a payload (retain__store()). A kw that carries a binary field and that others hold now reaches the treedb as a twin of its own (kw_twin()); and the create-node / update-node commands and EV_TREEDB_UPDATE_NODE put the bytes of the file columns into a record of their own, not into the sender’s record (which kept a gbuffer the treedb had released). In 7.25.22 (since the file columns). c_mqtt/will_acl (its memory check: two wills and a retained payload not freed before), test_c_assets (the sender’s record keeps no gbuffer).

• MQTT broker: the will message obeys the ACL. will__send() published it with no check, so with enable_acl on a client could publish, as its will, to a topic its groups refused. It is asked like any publish when it is sent; a refused will is not published, with a warning (c_mqtt/will_acl: raw MQTT clients, a will refused and one allowed; red without the check: the refused will reached the subscriber). And the enable_acl description and mqtt_broker.md say what the ACL is not: it is keyed by the client_id a client chooses, and no client is bound to the user that authenticated it, so it separates topics, not users.

• CLI (yunetas 0.20.4 on PyPI): yunetas build warns when two builds install a yuno of the same role in outputs/yunos, where the last one overwrites the other (yunovatios’ gate_caudal reached hidraulia that way): a red WARNING per role, read from each tree’s install_manifest.txt.

• Tests: test_secret_attrs’ no-fallocate case no longer passes untested when the seccomp filter cannot be installed (the child exits 2); test_rt_disk_overflow’s reborn case no longer hangs to the ctest timeout when its room was not made (a size_t subtraction wrapped).

• timeranger2: a negative from_t / to_t / from_tm / to_tm is relative to the key’s last record again. Since v7 it reached the matcher raw, compared with an unsigned __t__ (-86400 became ~1.8e19), and no record matched, silently: a db_history that starts with from_t=-86400 (hidraulia, estadodelaire, wattyzer) never read what had arrived while it was stopped. get_segments() resolves it against the key’s last record -- its t, and its tm (the last row of the file that holds the key’s highest t): from after last - N, that bound excluded; to up to last - N. (Before v7 it was the TOPIC’s last record, of any key; a v7 topic is read per key.) It is written back into the condition of that key alone: a list of several keys resolves it per key (each iterator gets its own copy of the condition, in tranger2_open_list() and C_TRANGER’s open-list); the realtime half of such a list keeps the bound unresolved -- there is no one last record for all its keys -- so a negative from bounds nothing there and a negative to takes no new record. The matcher compares signed, and on a key with no record yet a negative from bounds nothing and a negative to takes no row. test_tm_order (the three read roads, both ways, master in memory, reloaded, replica; a tm against the last record’s, not the highest one, which only the master in memory knew; a list of two keys with different last records) and test_c_tranger (open-list over two keys).

• Builds on a glibc older than 2.34. The daemon start closed its inherited files with close_range(), whose glibc wrapper is 2.34’s: a source build on an older glibc did not compile. It calls the system call directly (syscall(SYS_close_range)), with the loop as before where the kernel lacks it. Kernel headers older than 5.9 do not define its number: it is given (436, the same on every architecture built), or such a build would always take the loop.

• fs_watcher: a directory watched again brings its subtree. Under FS_FLAG_RECURSIVE_PATHS, a directory that could not be watched (out of inotify watches) was watched alone when watches came back: a subdirectory made in it meanwhile was never watched, and nothing made in it was heard. Its subdirectories not watched are queued behind it now, and each is watched and handed as created, parent first -- within the batch’s bound: every try of a batch counts against its 64, an ENOSPC/ENOMEM ends them, and a directory is looked up by its path, not in the whole table of watches (a tree of 100000 keys, at the moment watches ran out, would have blocked the loop). “Directories watched again” is said at the end of the batch where none is left, not while a subtree is still queued. A directory renamed during an overflow and watched again at its new path no longer leaves its old path in the index, where a directory made later there was taken for one watched. A readdir() that fails half way (EIO, ESTALE) is said, in the re-watch and in the pass after an overflow, not taken for the end. And the first walk of a recursive watch takes hidden directories too, as IN_CREATE and the pass always did: a .name there before the watch was never heard. For C_FS and the watch utilities with recursive: a tree that already holds a .git or a cache now takes inotify watches, and events, for all of it at the start. The pass after an overflow no longer follows a symlink to a directory (the first walk and the re-watch never did), and a failed fstatat() there is said. The half-of-the-open-files warning has a hysteresis (said again only after the count fell under 40%, not on every swing around the half), and an unparsable max_queued_events is said, as an unreadable one was.

• C_TCP: nothing of the gobj is touched after EV_DISCONNECTED if a host destroyed it there. set_disconnected() published the event and then reset the gobj’s volatile attrs: a host that destroyed a transport on that event would have been a use after free (none in the tree does). The publish is guarded by the liveness marker of 7.25.22.

• ytls: a subscriber’s errors are not summed into TLS codes; OpenSSL’s write stall is bounded. flush_clear_data() summed the answers of on_clear_data_cb into the number space of -2222 (the session freed) and of the “< -1000: a TLS error” band: more than 1000 records answered -1 in one read became a TLS error and closed the connection, and a sum of exactly -2222 left it hanging. It answers -1 now, however many. OpenSSL’s encrypt_data() looped on WANT_READ/WANT_WRITE with no bound; it stops after 5 tries in a row with a warning, as mbedTLS does (a write that progresses starts the count again). OpenSSL’s flush_clear_data() checks gbuffer_create(). And C_TCP reads the -1 the same way on the flush that follows the handshake: a subscriber that answered -1 to the first data, arrived with the handshake, closed the connection as for a TLS error; only a TLS error (below -1000) does now, as on the decrypt path.

• gbuffer_printf() writes a text that fits exactly. vsnprintf() was given the free bytes only, not the byte every gbuffer keeps for the NUL: a text of exactly the free bytes was refused (“MAXIMUM SPACE REACHED”) when the gbuffer could not grow, or, grown to exactly the text, written one character short with “NOT ENOUGH SPACE” and the NUL counted as data.

• C_AUTHZ with no users treedb refuses add-jwk / remove-jwk. Such a yuno (local access only) validates no JWT, and asked nobody whether the caller could change its keys: any valid JWT could add one. The key was never used, and leaked (4.4 KB per key, seen by the test). They are refused now, with “no users treedb in this yuno: local access only, no JWT is validated here”; list-jwk answers, with the keys of the config (jwks), which such a yuno never uses.

• A persistent attr the gclass no longer persists is said at load. The load wrote only the SDF_PERSIST attrs of the file and dropped the rest in silence, while every save kept them in the file: the jwks that add-jwk persisted before 7.25.22 (now the config’s) vanished at the first restart, and a node whose keys came only from there lost its JWT logins with nothing in its log. The load now warns once per attr (“Persistent attrs file holds an attr that is not persistent: NOT loaded”); remove-persistent-attrs drops it from the file.

• Agents’ units: ExecStopPost works on a v1 or hybrid cgroup host, and says what it kills. It read /sys/fs/cgroup/system.slice/%n/cgroup.procs, a v2 path written by hand: a no-op, unsaid, elsewhere, and its kills left nothing in the journal. It asks systemd for the unit’s ControlGroup, reads it under the v2, hybrid or v1 mount, loggers each pid it kills (and each kill that fails), and says when no cgroup was found.

• Agent: a yuno still alive 10 s after a node bounce gets no second instance. restart_nodes() waits for the yunos it killed, and after 10 s relaunched them anyway, without asking whether they were alive: a yuno stuck in a disk wait got a second instance. Those are now spared, listed by “yunos killed for the restart still alive after 10 s: each one launched when it is gone”, and each one is launched when it is gone: looked at every second, for 5 minutes, after which the warning says to run-yuno them. Gone is every pid the restart killed gone AND no process left running the yuno (its role and configuration). A pid is gone when it does not exist, is a zombie, or runs with another start time than the one recorded when it was killed -- a pid reused by another process; a task in D state is alive, whether or not it still has its command line (it loses it while it still holds its files), and so is one whose /proc/<pid>/stat cannot be read (logged). A pid gone before it was recorded is not waited for. Only those are launched. A spared yuno the operator stops (kill-yuno), disables or launches meanwhile leaves the window; one stopped, disabled or launched in the first 10 s is held apart, not run by the relaunch nor spared (enable-yuno, in those 10 s only, takes back a disable, not a stop or a launch of the same yuno).

• Agent: kill-yuno of a yuno found only by the scan says it is not waited for. Such a yuno is signalled and the answer comes at once; a run-yuno sent before it is gone finds it alive and does not launch it. The answer now says so.

• Restarts without root put the agent back in its unit. /yuneta/bin/restart-yuneta (the certbot hook’s fallback) and logcenter’s default restart_yuneta_command (on a queue alarm) restarted the agent, as user yuneta, with yshutdown and yuneta_agent --start: with the agents’ units (7.25.22) that agent ran OUTSIDE its unit, where systemd does not see it and the next boot does not start it. Now, where the units are, restart-yuneta stops the yunos (yshutdown --no-kill-agent, plus its arguments) and restarts the unit with sudo -n systemctl restart yuneta_agent.service; it refuses, and says so, when sudo does not allow it. A node without the units keeps the old way. logcenter’s default runs restart-yuneta -s where it exists (logcenter is not stopped), and logs an ERROR when the command fails or is refused (exit code, or the signal that killed it), or when none is configured: only a system() that could not run was said. The text names no cause it cannot know. It waits for the command as before -- under the units, the agent’s restart. agent22 was never touched by yshutdown, and is not now.

• /etc/init.d/yuneta_agent answers what the units answered. Under systemd, start, stop and restart exited 0 whatever the units did (only logged), so service yuneta_agent start reported success with the agent’s unit failed; status asked only the units, so an agent running outside its unit read “not running”. Now each exits with the units’ answer, and status says “running OUTSIDE its unit (start puts it back)”.

• C_TIMER0: a stopped timer no longer ends the yuno’s loop. Its callback answered -1 when its gobj was not running, and yev_loop ends the loop on a -1: the cancel of a child timer stopped while the yuno runs -- the control center’s mt_stop clears and stops its rates_timer -- stopped the whole yuno whenever the service was stopped alone. It answers 0 now; the loop ends with set_yuno_must_die(), as it always did. And a gobj_stop() followed by an arm in one turn now says EV_STOPPED when the cancel comes back (it said nothing, and left the arm noted on the stopped gobj).

• --stop checks its signals, and a stopped daemon is not relaunched. kill() was never checked: on EPERM (an agent of another user) --stop waited 10 s, printed “killed (SIGKILL)” and exited 0. And the watcher ignored SIGQUIT, so a child that crashed during its orderly stop was relaunched 2 s later; at 10 s the watcher was SIGKILLed and the new child left alive, an orphan. Now the watcher notes SIGQUIT (SA_RESTART) and does not relaunch the child that ends after it, whatever its end; daemon_shutdown() signals the watchers first, then their children, checks every kill() (a refusal is said, not waited for, and --stop exits 1), and before the SIGKILL scans the name again, so a child started meanwhile is killed too. And it takes only the processes of the name that were STARTED as it (the base name of argv[0], from /proc/<pid>/cmdline): the SysV script /etc/init.d/yuneta_agent, root’s and of the same name, was signalled by the --stop it ran -- a script’s argv[0] is its interpreter. An agent of another user is taken, so its EPERM makes --stop exit 1, and so is one whose binary was renamed (*.bak-pre-<version>) or replaced on disk. (A first form of this compared /proc/<pid>/exe, which another user’s process does not let read, and which follows a rename: both left the agent up and exited 0.) A name and an argv[0] are whatever a process’s starter chose, so the list of processes has no fixed size: 64 look-alikes, made first, pushed the real agent out of a list of 64, and it was left up -- run as root too. A zombie of the name is dead and makes no EPERM; a cmdline that cannot be read for another reason than the process’s end is said, and --stop exits 1 (it is not known whether it was the daemon). daemon_shutdown() returns int (was void). The agents’ units send SIGQUIT to the watcher ($MAINPID) before the agent, so a stop under systemd does not relaunch it either.

• C_WEBSOCKET / C_PROT_TCP4H: a frame of exactly the default max no longer hangs. With max_payload_size / max_pkt_size at 0 the max was the yuno’s max block, but a gbuffer holds one byte less than its block (its NUL): a frame of exactly that length was taken, its buffer could not grow to hold it, istream_consume() dropped the bytes in silence, and the frame waited for its timeout. The max is now what a gbuffer holds (the max block less one byte), and a configured value above it is capped to it; such a frame is refused like any frame too big. istream_consume() checks what gbuffer_append() answers: a buffer that cannot hold the bytes asked for is an ERROR, and the frame is not completed cut.

• Deprecated C_PROT_MQTT: a packet longer than a gbuffer holds is refused. Its payload buffer is capped at the max block, and the remaining length was not: such a PUBLISH, which a peer can send, was delivered cut, and with the check above it never completed and logged an ERROR with a stack per chunk. It is refused at its header now (“Mqtt packet too large”, a warning) and the connection closed, as tcp4h and the websocket do.

• Tests: the memory check of c_prot_tcp4h/test1 measured get_cur_system_memory(), which is 0 without CONFIG_DEBUG_TRACK_MEMORY -- empty on the nodes. It measures mallinfo2() now.

• C_UDP_S / C_UDP: a subscriber’s error does not stop the reading. The read was re-armed only when the publish of EV_RX_DATA answered 0, taken as a sign that the gobj lived: one subscriber answering -1 (or an “Event NOT DEFINED”, which the publish sums) left the server deaf, with nothing said -- the defect fixed in C_TCP in 7.25.22. Now, as there, a marker on the stack says whether the gobj lives after the publish, and the read is re-armed whenever it does and the event is idle.

• rpm: the agents’ SELinux label survives a relabel. %post labels the web server’s wrapper and the two agents bin_t with semanage fcontext, and fell back to chcon when semanage was missing -- which the spec did not require. A chcon label is lost on an autorelabel or a restorecon -R /yuneta, and then both agent units fail at boot with 203/EXEC. The package now requires policycoreutils-python-utils where selinux-policy is installed (a rich dependency, for %post and %postun), says it when it still has to fall back to chcon, and takes the three rules out of the policy on erase.

• BREAKING: write-attr writes only SDF_WR attributes. gobj_is_writable_attr() answered TRUE for SDF_WR OR SDF_PERSIST, so every persistent attribute was writable at run time by write-attr, which only the per-command gate guards (off by default) -- around the checks of the attribute’s own command. C_AUTHZ’s max_sessions_per_user could be set without the update permission set-max-sessions asks for; C_IDP_KEYCLOAK’s kc_base_url, C_YUNO’s allowed_ips / denied_ips (not normalised either), emailsender’s url / password, and the rest, were open the same way. Now SDF_PERSIST without SDF_WR is set by the config or by its own command; write-attr answers “attr not writable”. Upgrade: a script that set such an attribute with write-attr uses the config or the attribute’s command instead; a gclass that wants one writable at run time declares it SDF_WR|SDF_PERSIST.

• dbsimple: a yuno run as root takes its user from the chain closed from / down. For a yuno run as root, the persistent attrs file of the yuno’s user is trusted, and that user was the owner of the first closed directory found going UP from the file. A member of the yuneta group could rename the data directory away (its parent is 02775), make one of their own 0755 -- or a symlink to one -- with their file in it: the walk stopped there, the file was loaded, and the next save was fchowned to them with the yuno’s secrets. Now the walk goes DOWN from / with openat(O_NOFOLLOW), and the yuno’s user is the owner of the lowest directory of the chain closed to others, each one owned by root or by that user (/yuneta/realms on a node); it ends at the first directory others can write, or of a third user. A symlink met inside that chain (/yuneta -> /srv/yuneta) is followed -- only root or the chain’s user can have put it there -- and its target is walked from / under the same rules, the user named so far still holding; a .. is taken as the parent of the directories walked, without what the directories it leaves had named (/a/X/../W does not trust the owner of X). (A first form of this stopped at any symlink, and a root yuno under a linked /yuneta refused its own files.)

v7.25.22-3 (2026-10-02)¶

A packaging revision, not a new version: the code is 7.25.22’s, and the packages are attached to the existing tag 7.25.22.

• /etc/init.d/yuneta_agent drives the two agents’ units. Under systemd the script was redirected to yuneta_agent.service alone on Debian (by /lib/lsb/init-functions), so agent22 was out of its reach; on RHEL it was not redirected at all, and a start launched both agents by hand, outside their units. Now it skips that redirect and drives the units itself, the way the SysV script always treated the pair: start starts the main agent’s unit and then, once it is up, agent22’s (a broken binary never takes both down); stop stops the main agent alone, agent22 keeps running; restart restarts the main agent and starts agent22 only if it was not running; status reports both. An agent running outside its unit (a hand --start) is stopped first and started in it -- found by its executable (/proc/<pid>/exe), because the script is named yuneta_agent too and pgrep -x yuneta_agent finds the script itself. service yuneta_agent22 ... and systemctl still drive one unit alone. Root is needed, as su - yuneta always required.

v7.25.22-2 (2026-10-02)¶

A packaging revision, not a new version: the code is 7.25.22’s, and the packages are attached to the existing tag 7.25.22.

• rpm: the agents’ units start under SELinux. 7.25.22-1 runs the two agents in native systemd units, and systemd (init_t) cannot exec a default_t file -- everything under /yuneta is, outside the policy. On yunovatios-central (Rocky 9, enforcing) the agent’s unit died with 203/EXEC, “Failed to locate executable /yuneta/agent/yuneta_agent: Permission denied” (avc: denied { execute } ... scontext=init_t tcontext=default_t), and %post, as designed, left agent22 running outside its unit rather than stopping both. %post now labels /yuneta/agent/yuneta_agent and yuneta_agent22 bin_t (semanage fcontext + restorecon, chcon where the policy tools are missing), as it already did for the web server’s wrapper. A binary moved in by hand on such a node takes the rule back with restorecon. The .deb is unchanged (Debian runs no SELinux by default).

v7.25.22 (2026-10-02)¶

What changed after 7.25.21: the defects, the nits and the risks of two reviews -- of 7.25.21 itself, and of the fixes made for it -- and the open defects of TODO.md section 1. Each fix has a test that fails on the code before it, except the hook and the entries this list marks “(no red test)”. Two items stay open, in TODO.md: the accounting of key deletes in rt_disk followers (its design is decided: a sequence in the master’s signal, which changes the protocol between processes, so it gets a release of its own), and code of the projects, moved to their own TODO files.

Performance, against 7.25.21¶

Measured against 7.25.21, each release built from its own tree, the two run alternately (8 rounds, 24 for the timeranger2 tests); the report is performance/reports/7.25.22.html. A forced treedb delete takes 39% less time (69.8 -> 42.5 us): a delete no longer walks every open key. Nothing is slower on a path this release changed. Four figures moved outside their spread on code that did not change, and are not claimed: appends -1.9% per second (-1.6% with a live reader) and a treedb update in memory +5.0% of time, slower; the appends to a store of many keys -8.5% of time, faster -- placement of the code in a whole-release build.

Upgrade steps (operators, read first)¶

• The command attrs run with system() are set in the config only: the agent’s cert_sync_copy_cmd and cert_sync_store_dir, logcenter’s restart_yuneta_command. A value set at run time with write-attr and persisted is no longer read: put it in the yuno’s config ("global": {"agent.cert_sync_copy_cmd": "..."}).

• C_AUTHZ asks the permissions of its users treedb (treedb_authzs) for every command from a peer, with the per-command gate off too: read to list, create/update/delete to manage users, update for the JWKs, check-user-pwd and set-max-sessions. A gui_agent operator with no such permission now gets -403 in the Users workspace. command-yuno forwards the operator’s __username__, so the operator is asked in the target yuno’s OWN treedb: an operator who manages users in the agent may get -403 in another yuno. A yuno with no users treedb (local access only: logcenter, auth_bff, sgateway, watchfs, dba_postgres) answers the user commands -1, “no users treedb in this yuno: users, roles and permissions are not managed here”, and the jwk commands as before.

• A persistent attrs file of another user is refused (not loaded, saves refused) unless it is root’s, or the yuno runs as root and it is its user’s (the owner of the nearest directory above it that nobody else can write: /yuneta/realms on a node) -- and even then when the group or others can write it. A root file left 0664 by a release before 7.25.19 is refused: make it 0600. A node whose yunos changed of user (a dev box: yuneta after a reboot, the developer’s own user by hand) gives the files to the yuno’s user.

• C_AUTHZ’s jwks and default_role are set in the config only. A value persisted by an older release (write-attr, add-jwk) is no longer read: put the keys in Authz.jwks and the role in Authz.default_role. add-jwk / remove-jwk still change the running set, until the yuno restarts. yunovatios sets default_role with write-attr in its deployment notes: move it to the batch config.

• A frame before the session is limited (max_pre_session_frame of C_IEVENT_SRV, 64 KB by default): a client that sends a bigger identity card needs it raised.

• register-idp-user with a role answers -403 to a caller without the update permission of treedb_authzs (as create-user asks to link one). An operator who registers people with a role needs that permission; without a role it is answered as before.

• kill-yuno of a yuno alive but not connected answers at once: the yuno is signalled and not waited for. A run-yuno sent right after it can find it still exiting and not launch it (“not launched again”): wait for it to be gone (list-yunos, or its pid) before running it.

• Rebuild every project against the new headers. fs_event_t (fs_watcher.h) gains ten fields, at its end.

• An rt_disk follower holds one more descriptor per key directory of each feed (FS_FLAG_DIR_FDS). A yuno now raises its soft open-files limit to its hard one at its start (C_YUNO limit_open_files, 0 by default; up to 7.25.21 0 left it as it came, and a yuno started from a desktop session kept the soft 1024); the packages give the yuneta user nofile unlimited. A follower that is not a yuno raises its own.

• A stop of a TCP connection no longer waits for ever for a peer that does not take its data: after timeout_stop_tx (10 s by default, a new C_TCP attr) the connection is aborted. A host that stops a connection expecting a slow peer to drain more than 10 s of data sets it higher, or 0.

• Two C_TCP_S of the new method on one pool of channels are refused: the second leaves the first’s channels to it with an ERROR. That pool was never shared (the second took every channel, silently); a shared pool is for child_tree_filter.

• The agent’s audit log redacts more names: one that holds a part of a secret’s name is redacted whatever else it holds (token_endpoint too).

• The agents run as systemd units: yuneta_agent.service and yuneta_agent22.service. Start, stop and restart them with systemctl; an agent started by hand with --start runs outside its unit, where systemd does not see it and the next boot does not start it. To deploy an agent binary: move it into place, then sudo systemctl restart yuneta_agent (one agent at a time, as always). The package’s upgrade moves both agents into their units (agent22 too, which the SysV script started outside any unit). A restart of an agent’s unit leaves the yunos running (KillMode=process; its journal says “Found left-over process” for them).

• A direct owner of an fs_watcher handles FS_WATCHER_GONE_TYPE: the watcher tells it before it goes, already freed when the callback returns, so the owner drops its pointer and never stops it again. timeranger2, C_FS and utils/c/fs_watcher do; no project owns one directly today.

• gobj_stats() of a C_IOGATE or a C_QIOGATE answers the envelope ({"result", "comment", "schema", "data"}) like every other mt_stats; the counters are under data. A project that read them bare reads 0 now: yunovatios’ c_sim_controller.c was migrated (it reads the queue’s msgs_in_queue / pending_acks attrs). A C_CHANNEL read by its parent still answers the bare data.

• C_YUNO’s uptime is in seconds since the yuno started. It was the MACHINE’s uptime in jiffies (/proc/uptime × HZ). A chart or an alarm on it changes of unit; the machine’s uptime is now asked with the new command info-uptime.

Fixes¶

• emailsender: set-email-user sends what was queued while the credentials were missing. The session connects only for a message it holds, and the command only started it: an email queued before the credentials waited for the next one queued, or for a pause and a play. Test emailsender/set_user_queued.

• emailsender: skip-email no longer repeats the “username or password is empty” ERROR. It started the SMTP side after every skip, whatever it was before, so a service playing without credentials said its ERROR once more per skip. It restarts the side only if it had been started. Test emailsender/skip_no_credentials.

• emailsender: skip-email of an email in its mail transaction no longer stalls the queue. The stopped session stays in its transaction state until its C_TCP reports the close, and refused the next email there (“Event NOT DEFINED in state”); the close of a stop tells nothing, so the queue waited for the next email queued. C_SMTP_SESSION now takes EV_SEND_MESSAGE in those states too, and the email goes on the next connection. Test emailsender/skip_in_flight.

• SECURITY: a positional secret written with blanks is not echoed. A required SDF_SECRET parameter given without its key and with blanks in it (set-password-pos correct horse battery) took the first word, and the answer “command ... with extra parameters” showed the rest in clear. It now shows '<...>', as for the same secret written as key=value. Test secret_attrs.

• SECURITY: the ievents trace masks a command by its table. It masked by key names only, so a positional secret of a v7 command (in __md_iev__) went in clear; it now masks like ievents2 (ievent_kw_masked()). Both traces log an ERROR and trace nothing if the masking fails, instead of a silent failure of json_pack(). Test secret_attrs.

• yunetas-env.sh can be sourced with set -u. It read two variables that nothing sets ($dir, $pwd_opt), so the cloud SessionStart hook, which runs under set -euo pipefail, stopped there with YUNETAS_HOOK_BUILD_C=1, before the external libraries and the C build.

• gbuffer_serialize() of a NULL gbuffer answers NULL, logged. It read the gbuffer’s secret flag first: a segfault. Test gbuffer (test_gbuffer_guards).

• SECURITY: a secret json parameter that does not parse is not logged. A DTP_JSON/DTP_LIST/DTP_DICT parameter marked SDF_SECRET was parsed with the verbose parser, which logs the text it could not parse (an ERROR and a dump). It is now refused naming the parameter only (“parameter ‘<name>’ is not a valid json”). Test secret_attrs.

• emailsender: a line or a DATA body that cannot be built is not sent half-built. The CRLF and the .\r\n appended to it, and the json_pack() of the frame, were not checked: the line is now refused with an ERROR, and the body ends the session as an error of ours. Only out of memory reaches them (no red test).

• Agent: a configuration file of a yuno with a long name is written. Its temporary file was the name of the file with 8 bytes more, so a name a few bytes under NAME_MAX failed with ENAMETOOLONG and the yuno was not run. The temporary file is now .config.XXXXXX in the yuno’s bin/. Test helpers (test_yuno_config_file).

• Agent: the temporary configuration files that an interrupted write left are removed at the agent’s start, for every yuno. Only the next launch of that yuno removed them, so a yuno not launched again kept them; both names (.config.XXXXXX and the 7.25.21 one) are recognised. Test helpers (test_yuno_config_file).

• fs_watcher: an entry whose IN_IGNORED was lost in an overflow is forgotten. A wd stopped by the pass after an overflow (a directory deleted and created again, or no longer there) kept its entry for good when its IN_IGNORED went with the overflow. It now goes once the stream is past where that event would have come. The directories the pass did not visit are asked to the filesystem, only those: no lstat() per watched directory. fs_event_t gains three fields, at its end. Test timeranger2 (test_fs_watcher_overflow).

• scripts/check_test_ports.py fails on a file it cannot read, naming it: it skipped it silently, and its ports were not checked. Its files are closed after reading.

• SECURITY: a required secret parameter must be the last required one. gclass_create() refuses, with an ERROR, a command table where a required secret (SDF_SECRET, or a secret’s name) is followed by another required parameter: written with blanks, the secret spilled a piece into the next parameter (shown in the traces and its errors) and the rest into the “extra parameters” answer. No command of the SDK or of the projects declares one. Test command_secret_positional.

• yev_loop: a kernel too old for Yuneta stops the yuno at its start, and says why. yev_loop_create() probes the io_uring operations the loop uses and tries the cancel of everything with which a loop stops (IORING_ASYNC_CANCEL_ALL|ANY, Linux 5.19); missing one, a CRITICAL (“Linux kernel too old for yunetas: it needs Linux 5.19 or later (or RHEL/Rocky/Alma 9)”, with lacks and kernel) and an abort. On 5.6 to 5.18 a yuno started and could not stop its events. The minimum kernel is now documented (installation, README). (no red test: every kernel at hand has them; the probe checked on 7.0, 6.12 and Rocky 9.7’s 5.14)

• C_TCP: a connection dropped from inside its own EV_RX_DATA no longer uses itself after its EV_STOPPED. EV_STOPPED is where the host of a volatile C_TCP destroys it: a clisrv of the legacy method in a channel with no C_TCP of its own (in this tree, sgateway’s input). A host that dropped such a connection while handling its data (a websocket refusing a request that is not HTTP) destroyed it inside its own stack, and the C_TCP then read its url (set_disconnected()), and over TLS took ytls’s -2222 (the session was freed inside the callback) for a TLS error, wrote the cause and stopped the destroyed gobj again. Now EV_STOPPED is the last thing a C_TCP does with itself, and -2222 is a return: set_disconnected() ends there (the client’s idle_closed is consumed before it), mt_stop() releases the TLS session and the queues BEFORE the stop of its events, and both TLS backends answer -2222 from the encrypt path too, where write_data() used the released gbuffer. The volatile attrs are reset where a stop ends, no longer in mt_stop(). Test c_tcps/test7 (red: a SegFault in clear and over TLS); the mt_stop() order has no red test (a connected clisrv always has a read in flight, so its stop never ends inside mt_stop()).

• Agent: an orderly --stop with a run-yuno (or kill-yuno, play-yuno, pause-yuno) still waiting logs nothing. Each of them arms a volatile C_COUNTER that waits for the yunos (30 s); the yuno stops only its direct children, so a counter still waiting reached gobj_end running: “Destroying a RUNNING gobj” and “No subscription found” per counter. The agent’s mt_stop stops and destroys them, without answering (their channels are closing). (no red test)

• SECURITY: write-attr can no longer plant a trusted signing key nor hand root to IdP users. C_AUTHZ’s jwks and default_role were SDF_WR|SDF_PERSIST, so write-attr -- guarded only by the per-command gate, off by default -- could add a JWK that the next start trusts, or set default_role to root for every user an IdP provisions. Both are SDF_RD, the config’s. Test command_delete_user (red: the role was written).

• C_AUTHZ with no users treedb: the jwk commands answer again, and the user commands say why they cannot. The always-on permission check of this cycle asked a treedb that a yuno of local access only does not have (logcenter, auth_bff, sgateway, watchfs, dba_postgres): every command from a peer, list-jwk included, got -403. The jwk commands, which never used the treedb, are answered as before; the user commands answer -1 naming the cause. (no red test: no test yuno runs a C_AUTHZ without a store)

• stats=__reset__ zeroes the counters of C_TCP, C_TCP_S and C_UDP_S. The reset writes the defaults of the SDF_RSTATS attrs, but these gclasses read their counters from private fields (mt_reading), which nobody zeroed: a reset changed nothing. mt_writing zeroes them now (txBytes, rxBytes, txMsgs, rxMsgs, max_tx_in_progress, refusedConnxs, noChannelConnxs, rxRefusedMsgs). Tested for C_TCP_S and C_UDP_S; C_TCP takes the same code.

• --pid-file without --start is refused at the start, instead of being ignored in silence: there is no watcher whose pid it could hold.

• A daemon closes every inherited descriptor with close_range(). The loop up to _SC_OPEN_MAX missed one inherited above a soft limit lowered after it was opened, and under the limit the agent’s CLI sets (1048576) it made a million close() calls. The loop stays for a kernel without close_range (no red test: checked by hand, a yuno started with fd 50 open under ulimit -Sn 20 keeps only its own).

• C_YUNO info-uptime names the right error. It read errno after the log that may change it.

• fs_watcher: the half of the open-files limit is the process’s. The warning counted the descriptors of each watcher alone, while EMFILE is per process: four followers of 400 directories each, under 1024, never said it. It counts every watcher’s now, and says it again only after they fell under the half.

• fs_watcher: an end said when FIONREAD fails is never short, and a FIONREAD that keeps failing ends the watcher. The end added a read whole to what it could not count: with more queued, the owner did too soon what it left for after those events. It adds all the kernel can hold now (max_queued_events). And the turn that closes that end, when FIONREAD fails again, tells the owner FS_WATCHER_GONE instead of waiting for the next batch, for ever on a quiet watcher.

• C_TIMER0: a timer cleared and armed again in one turn of the loop runs. A pause and a play together (the control center’s rate tick) armed the timer while its cancel was in flight: “cannot start timer: is CANCELING”, and the timer stayed off until the next play. The arm is kept and done when the cancel ends, and that cancel is not published as EV_STOPPED.

• ytls: the causes with no reason say it. A peer’s close_notify under mbedTLS ended the connection as “TLS: decrypt failed” alone; data to encrypt before the handshake ended (both backends) and the mbedTLS write that makes no progress gave no reason either. They are said now (“the peer closed the TLS session (close_notify)”, “data to encrypt before the handshake ended”, “the write made no progress”), and C_TCP puts them in its disconnect_cause. Tested on both backends (mbedTLS linked by hand: the local build has OpenSSL only).

• timeranger2: a feed of metadata only is fed a record whose body is lost. A follower that could not read a record’s body (on the by-path fallback, a life already deleted) skipped the record for every feed; the feeds that want the body still skip it, the ones of metadata only get it (no red test: the fallback needs a system without /proc).

• timeranger2: on a master, a file missing from a key still on disk is a damaged store, a CRITICAL. Cannot open file to read / Cannot open md2 file with ENOENT was a warning (“its key deleted under the reader”) everywhere. A master deletes a key whole, in its own process: when the key’s directory is still there, the reason is now “missing from a key that is on disk: the store is damaged”. A follower, or a key gone, keeps the warning.

• rmrdir() walks once more a directory filled while it was walked, and logs only a second failure. An entry made by another process after the last readdir() failed the rmdir() with ENOTEMPTY, an ERROR, even when the caller’s retry removed it (a reader closing an rt_disk feed the master was still linking into, which now calls it once).

• timeranger2: the leftover of a closing feed whose pid was reused is removed. .closing.<pid>-<start>.<seq> carries the start time of the reader’s process; the master removes one whose pid lives but started at another time. Up to 7.25.21 it stayed while the unrelated process lived.

• --stop gives a daemon 10 s for its orderly shutdown. Every process of the name gets SIGQUIT at once, and only the ones still alive after 10 s are killed (said on stderr). Each was killed 1 s after its own SIGQUIT, one after the other: the agent had one second to stop its yunos and save, and a --stop always took two seconds (the watcher, deaf to SIGQUIT, waited its whole second). The packages use --stop to move an agent into its unit. (no red test: checked by hand, a watchfs --stop takes 109 ms and leaves nothing)

• fs_watcher: a subdirectory whose watch cannot be made is watched later, and timeranger2 reads its records. Out of watches (ENOSPC at max_user_watches) or memory, the directory was never watched: a follower took the key directory for gone and lost every record of the key, with an ERROR per directory. It is tried again at the end of each batch of the watcher, and handed as created again once watched (its owner reads what was made meanwhile); said once when it starts and once when every directory is watched.

• C_TCP: a subscriber’s error no longer stops the reading, and nothing is touched after a publish that destroyed the gobj. A subscriber of EV_RX_DATA that answered an error (-1, its own) stopped the reading: the read was re-armed only on 0, used as a sign the gobj lived, and nothing stopped the connection either -- it hung in silence. The liveness is a marker now (a stack variable chained in priv, cleared by mt_destroy), around every publish that may end the connection or the gobj: EV_RX_DATA (clear and TLS), and EV_CONNECTED, after which set_secure_connected() flushed the session and set_connected() armed the inactivity timer whatever the subscriber had done. start_pending_writes() says when its write ended the connection. And OpenSSL’s flush of the encrypted bytes leaked its gbuffer (and could spin) when BIO_read failed. Test c_tcps/test8 (new; red: the second message never arrived; the EV_CONNECTED drop has no red test).

• C_PROT_TCP4H no longer reserves the length a peer announces, and a websocket frame of exactly max_payload_size ends. tcp4h reserved the whole length of a frame at its 4-byte header, before any payload, up to max_pkt_size (the max block by default): a peer that wrote only headers reserved it each time -- the reservation C_WEBSOCKET dropped earlier in this cycle. Its buffer starts at 4 KB now and grows with what arrives. And in both, the buffer’s max is what the frame needs + 1 (a gbuffer holds one byte less than its max): C_WEBSOCKET’s was max_payload_size, so a frame of exactly that size never ended. Tests c_prot_tcp4h/test1 (new; red: 10 MB grown for a header) and c_websocket/test2 (the frame at exactly the max; red: it hung).

• SECURITY: register-idp-user no longer hands any role to its caller’s pick. With a role, it checked only that the role existed, and the authz plane linked it when the IdP answered: a holder of register-idp-user gave root to an email of their own, with no permission on the users treedb. A role from a peer now needs the update of treedb_authzs, as create-user asks to link one: C_AUTHZ’s has_role answers may_link for the __username__ the IdP passes on. Test command_delete_user (red: the request was queued).

• SECURITY: dbsimple no longer reads a trusted file that others can write, nor trusts a data directory’s owner. A root file (or, for a yuno run as root, one of the yuno’s user) was read whatever its mode: one left 0664 by a release before 7.25.19, in the group-writable data directory, could be edited by any member of the group. And the yuno’s user, for a root yuno, was the data directory’s owner, while its parents are 02775: a member of the group could rename it away and make one of their own. Such a file is refused now, and the yuno’s user is the owner of the nearest directory above that nobody else can write. Test secret_attrs (case 7, red: the group-writable root file loaded); the root-yuno branch has no red test (a directory of another user needs root).

• C_AUTHZ: a username holding %s no longer crashes the refusal. The “User not found” warning of get_user_permissions() had a comma missing, so the username became the FORMAT of the log -- reached on every refused peer command since the always-on permission check, and a username is an email taken from a JWT. Test command_delete_user (red: SegFault).

• Agent: a node bounce relaunches the yunos once the killed ones are gone. restart_nodes() (deactivate-snap, activate-snap) sent SIGKILL to every yuno and relaunched them at once; a SIGKILL is delivered, not done, so a new instance could meet the old one’s exclusive resources, or the launch found the old one alive and skipped it. It waits now for the pids it killed (every 100 ms, 10 s at most, then relaunches and names the ones left). (no red test; on wattyzer the relaunch began 1 s after the kills)

• Agent: kill-yuno reaches a yuno alive but not connected. It selected only the yunos the agent saw running, so one that lost its channel or outlived a restart of the agent answered “Yuno not found or already not running” while it lived. Matching yunos alive in /proc (the search of the launch sweeps) now get the same signal on their watcher and child (signal2kill, SIGKILL with force=1) and are said at once in the answer with their pids: nothing will say they closed. (no red test: no agent harness; checked on wattyzer with a stopped webstats, 2026-10-02)

• ytls: a session freed inside ANY callback is no longer read. The owner (C_TCP) frees the session from inside a callback when a write cannot start or a subscriber drops the connection. Only on_clear_data_cb was covered: after on_encrypted_data_cb the backends went on reading the freed session (the loop of the flush, the log of a failed callback, the state of the handshake), and after on_handshake_done_cb the decrypt went on with it. Every call that hands control to the owner now keeps a marker, the markers are chained (the calls nest) and the free clears them all: each call returns -2222 on its way out -- ytls_do_handshake() and ytls_flush() included, which C_TCP now handles at the start of a handshake. Both backends. Test ytls/test_free_inside_callback (red: a SegFault on the poisoned session; mbedTLS run linked by hand).

• The agents are native systemd units, and systemd sees them. The agent was a SysV script that systemd-sysv-generator wrapped: an agent started outside it (by hand, by an xscript) left systemctl status yuneta_agent saying inactive while it ran -- an acceptance test on yunovatios central (Rocky 9.7) failed on it -- and yuneta_agent22 had no unit at all. yuneta_agent.service (named like the script, so systemd takes it instead of the generated one) and yuneta_agent22.service (independent: either can stop or fail while the other keeps the node reachable) are Type=forking over the agent’s own daemon: a new option of every yuno, --pid-file, makes the process started with --start write the WATCHER’s pid before it returns, which is the unit’s main pid. The watcher keeps relaunching a crashed agent (Restart=no: systemd never starts a second one); KillMode=process keeps the yunos across a stop; ExecStop asks only the unit’s own agent to shut down (not --stop, which ends every process of the name -- and systemd runs ExecStop also when the watcher ended on its own, so a second agent that met the first and left took the first with it). The package restarts both units (the main agent first, agent22 once it runs), stopping first an agent that runs outside its unit; the SysV script stays for another init. Checked by hand on wattyzer (Debian 13); through the built packages, and on Rocky, before the release (TODO.md). (no red test)

• The agents’ units: a removal of the .deb stops every unit, and a hung agent does not outlive its unit. The postrm disabled the units through a script of the package, which dpkg had already deleted: a removal left yuneta_agent22 running from a deleted binary (and the web server’s unit enabled). prerm does it inline now. And with KillMode=process the final SIGKILL of a stop that timed out reached only the watcher: an agent hung in its shutdown stayed in the cgroup; ExecStopPost kills what is left of the unit’s own agent there. Checked on wattyzer with a SIGSTOPped agent22 (no red test).

• gui_agent’s bottom bar no longer clips its fifth item on a phone (gobj-ui 7.25.24, gui_agent 0.29.8, gui_treedb 0.17.75). Bulma’s .level put a 0.75rem gap between items that carry their padding: at 360px the bar scrolled 29px in Spanish, 5px in English. Measured with the real Bulma in Chromium and Firefox.

• fs_watcher: an end of the queued events said past the stream is reached on a quiet watcher. When fs_queued_events_end() cannot see the watcher’s read (completions overflowed the ring, FIONREAD failed, the completions kept moving) it counts a read whole, about 8 KB past the real end; a timeranger2 follower that deferred the scan of a key directory to that end waited for as many bytes of unrelated events, for ever on a quiet feed. The watcher now notes such an end and closes it on the next turn of the loop (and after each batch while open): once nothing waits in the ring nor in the kernel, the stream jumps to it with an FS_BATCH_END. And a FIONREAD that fails inside a batch no longer answers the batch’s end alone, which could be short. fs_event_t gains two fields, at its end. Test timeranger2/test_fs_watcher_overflow (do_test_padded_end, with a __wrap_ioctl that fails FIONREAD once; red: no FS_BATCH_END comes).

• dbsimple: an in-place save whose write stops half way writes the old content back. In a directory the yuno cannot write, the persistent attrs are saved in place with ONE pwrite(): where the room cannot be reserved (NFSv3, FUSE) or the reservation does not cover a rewrite (copy-on-write: btrfs, reflinked XFS), an ENOSPC half way left the new start over the old tail -- a file that does not parse, so the next start loads the defaults and refuses every save. The old content is read first, the write is looped over short answers (the real errno is said), and a write that fails after some bytes writes the old content back, cut to its size and synced; the ERROR says “written back as it was”, or “UNPARSABLE” when that fails too. Test secret_attrs/test_secret_attrs (8, with a __wrap_pwrite that writes 16 bytes and then fails; red: the old content not back).

• timeranger2: a follower no longer takes a key directory for gone when it cannot tell which one it is. On the path without a descriptor per directory, dir_identity() answered FALSE with no log on ANY failure of statx(), and its callers skipped the directory’s scan: its links waited for the key’s next record, in silence. Now only a directory gone (ENOENT, ENOTDIR) is silent; a statx() refused (EPERM from a container’s seccomp profile, ENOSYS) takes the inode from lstat(), with the warning of no birth time; any other errno is an ERROR, once per errno in a row. Test timeranger2/test_dir_identity (red: 5 checks).

• C_TCP: the disconnect_cause of a TLS failure says the backend’s reason on mbedTLS too. mbedTLS never wrote the reason where C_TCP reads it (ytls_get_last_error()), so its causes were a bare “TLS handshake failed”, or "TLS: " with nothing after it. Every TLS cause is now what failed plus the reason when there is one (no dangling ": "), the flush of clear data and the decrypt included; “cannot create the secure filter” no longer appends the "???" of a session that does not exist; and a cause longer than its buffer (now 512 bytes) is truncated with a warning, no longer in silence. Test ytls/test_handshake_reject_mbedtls (the reason is empty without the fix; it needs CONFIG_HAVE_MBEDTLS).

• Control center: the rate tick is a real period, checked, and off while paused. It was a C_TIMER, which checks its deadline on the yuno’s timeout_periodic (1000 ms) and re-arms from when it was served: a tick of 1000 came every 1 or 2 s, and a burst of one second in a tick of two was halved in maxrxMsgsec/maxtxMsgsec. It is a C_TIMER0 now (io_uring, periodic). A timeout under 1 in the CONFIG was not checked (only a write was): the tick was off and the rates read 0 with nothing said; it is refused with an ERROR and 1000 put back. And paused, the rates read 0 instead of the last tick’s value. Test c_controlcenter_scenarios (test 12, red: the rates of the last tick while paused); the config check and the period have no red test.

• Control center: __input_side__ is not autostarted nor autoplayed in the realm configs of a.com (its operation repo, config 7, not deployed yet). The control center starts and plays it in mt_play, as __top_side__: autostarted, it listened from the yuno’s start, and an agent that connected to a control center run with play=0 logged “Publish event WITHOUT subscribers”. A realm config of your own does the same (the example is in controlcenter.md).

• C_QIOGATE: the size of its queue can be read through a C_MQIOGATE. msgs_in_queue and pending_acks were said only by the gate’s own mt_stats, and a C_MQIOGATE asks its children with build_stats(), which reads stats attributes and never calls a child’s mt_stats: stats-yuno service=__output_side__ showed no queue. They are SDF_RD|SDF_STATS gauges now, read live (mt_reading). And mt_stats no longer reads a closed queue (trq_size() of NULL). Test test_c_qiogate_stats (red: the counts missing for both children).

• stats-yuno on a C_IOGATE or a C_QIOGATE service answered -1 with no comment. Their mt_stats returned the bare data, written for a parent that reads its children, and C_IEVENT_SRV sent it back where the caller expects the envelope (gobj.h’s contract of mt_stats). Both build it now (build_stats_response()), and a C_QIOGATE reads its bottom gate’s counters from the data of the envelope. Test test_c_qiogate_stats (red: no envelope from either).

• The msg/s of C_IOGATE and C_CHANNEL no longer depend on who reads them, and when. The rate was the delta since the previous read divided by WHOLE seconds (a read 1.9 s after the previous one divided by 1: +90 %), and every read moved the window, a read under a second too, so the messages of that second went into no rate. The window is now 1 s at least, measured in milliseconds, and a sooner read answers the last rates without moving it. Two readers still share one window (each one sees the rate since the other’s read); the agent’s watch-yuno-stats is the one reader of a node. (no red test)

• C_YUNO’s uptime is the yuno’s, in seconds. Described as “Yuno living time”, it was the machine’s uptime in jiffies, read from /proc/uptime with every failure silent. It is now the seconds since the yuno’s mt_create, on the monotonic clock. The ESP32 yuno does not write it (it reads 0). (no red test)

• C_YUNO: info-uptime, the uptime of the machine. Seconds since boot (CLOCK_BOOTTIME, which counts a suspend, as /proc/uptime), the boot time and date it gives, and the yuno’s uptime and start date beside them. Test command_shutdown.

• C_TCP_S: a full server says it once a minute, as a warning, and counts it. With child_tree_filter, a connection that found no free channel logged an ERROR each time, and peers retry: 600 channels and 1000 simulated controllers made 38,156 of them in minutes. It is now a third cause of refusal, said on the transition like the ip lists (the first one, then one a minute with the count), as a WARNING (a matter of capacity), and counted in a new stat noChannelConnxs -- refusedConnxs stays for the ip lists. Test test_c_tcp_s_ip_lists (phase 4).

• A yuno raises its soft open-files limit to its hard one, and the descriptors of a follower are watched. With limit_open_files 0 (the default) C_YUNO left the limit as it came, so a yuno started from a desktop session ran with the soft 1024 of systemd --user, and a timeranger2 follower, which holds a descriptor per key directory of each feed, ran out (every record read failing). Now 0 raises the soft limit to the hard one (and a getrlimit() that fails no longer goes on with the limit unset). fs_watcher says once when its directory descriptors reach half of the soft limit, and a directory that cannot be opened (EMFILE) is said once, not per key directory: the next ones are counted, and the count is said when a descriptor opens again. Tests command_shutdown (the limit) and test_fs_watcher_overflow (dir fds limit).

• timeranger2: a follower does not hand a record without its body, and a read that finds its file gone is a warning. On the by-path fallback a record of a life already deleted could not be read and was handed with a NULL body to a feed that wanted the body; it is skipped now (the read logged it, and the delete comes next). And Cannot open file to read / Cannot open md2 file with ENOENT -- a key deleted under the reader -- are warnings (MSGSET_TRANGER, “gone: its key deleted under the reader”), not CRITICALs. (no red test: the fallback needs a system without /proc)

• SECURITY: C_AUTHZ’s commands ask a permission, always. They were SDF_AUTHZ_X only, which does nothing while enable_command_authz is off (the default): any user the entry gate let in created, updated, disabled and deleted users, set passwords, and added trusted signing keys (add-jwk), and linked a role through create-user role= that link-nodes refused. Now a command from a peer (its kw carries the __username__ of the entry gate) asks the permission of the users treedb’s own C_NODE, as link-nodes does: read, create (and update when it links a role), update, delete; -403 without it. Internal calls are not asked. Test command_delete_user (case 12).

• SECURITY: dbsimple refuses a persistent attrs file of another user. The data directories are group-writable (02775), so a member of the group could plant the file of any service, and the persistent attrs of the agent and of logcenter held commands run with system(); it was loaded, with a warning. Now only the yuno’s own file, root’s, or (for a yuno run as root) the data directory owner’s is loaded; any other is refused with an ERROR and the saves with it. A save as root gives the new file only to the data directory’s owner (it gave it, secrets in it, to whoever owned the old one). Test secret_attrs (case 7, with __wrap_fstat).

• SECURITY: the commands the agent and logcenter run with system() are config only. write-attr could set and persist cert_sync_copy_cmd (run as root through sudo, and at once by cert-sync-now, which had no flag) and restart_yuneta_command. They are SDF_RD now, and cert-sync-now / cert-sync-status are SDF_AUTHZ_X -- which, like every SDF_AUTHZ_X, guards them only where a yuno sets enable_command_authz (off by default, and no yuno sets it yet): the protection that holds today is the attrs being config only. (no red test)

• emailsender’s skip-email, remove-emails-failed, disable-alarm-emails and enable-alarm-emails are SDF_AUTHZ_X: they move or remove emails, or silence the alarms. The flag does nothing until the yuno sets enable_command_authz (off by default): it marks them for the day the gate is on. (no red test)

• A frame before the session is not parsed when it is big. C_IEVENT_SRV parsed a peer’s whole frame before checking its identity card, and a frame of [{},...] takes ~100 times its size to parse (16 MB: 1.7 GB): the max block of a yuno let an unauthenticated peer ask for ~20 GB. A frame bigger than max_pre_session_frame (64 KB) is refused with a warning, unparsed and not dumped. Test c_ievent_srv_identity_card (card 8).

• C_WEBSOCKET no longer reserves the length a peer announces. The payload buffer was created with the frame’s length from its header, before any of it came: a few connections each claiming the max block reserved it each. It starts at 4 KB and grows with what arrives, up to a new max_payload_size (0: the max block); a bigger frame is refused with a warning and 1009. Test c_websocket/test2.

• gbuffer: a buffer grown from small reaches its max. The growth doubles, and a doubling past max_memory_size was refused even when what was needed fitted (“MAXIMUM SPACE REACHED”): 4 KB with a max of 10 KB stopped at 8 KB. It grows to the max now, when what is IN it plus what is needed fits (a websocket frame of exactly its max, read into a smaller buffer, is the case that needs it). Test gbuffer (test_grow_to_max).

• timeranger2: closing a follower’s rt_disk feed under load no longer leaves its directory fed for ever. tranger2_close_rt_disk() removed disks/<rt_id>/ where it was, while the master kept linking new records into it: a key directory made in between made the removal fail (“rmdir() FAILED ... Directory not empty”, every orderly stop of a db_history_ce reading 3000 records/s), the directory stayed, and the master, which closes its side only when it hears the directory go, went on making a directory and a link per key and file into it (an id that never came back grew for ever). The reader now renames the directory away (disks/.closing.<pid>.<seq>) and removes the renamed one, where the master cannot reach it; the master’s watch of disks/ hears the rename as the close (new FS_FLAG_MOVED_AS_DELETED of fs_watcher), its link of a feed that is closing is quiet, and it removes at its next read of disks/ the .closing.* of a reader that died while removing it. A leading dot is no longer a valid rt id (“Invalid rt id (a leading dot is reserved)”, a warning): no id of the SDK or the projects has one. Test test_delete_key_propagation (close_races_master; red: the directory left, the master still feeding it).

• Agent: a yuno alive but not connected is no longer launched again. yuno_running / yuno_pid say only what the agent saw on the yuno’s channel and are not persistent, so a yuno that lost its channel, or that outlived a restart of the agent (a yuno still loading 13.7 M queued messages, 2026-09-26), was launched a second time by the boot sweeps or by run-yuno: the second instance opened the persistent queues of the first “as not master” and aborted, and when the first reconnected the agent killed it as the intruder. Before a launch the agent now looks in /proc for a process of that yuno (its role as argv[0], its configuration files in its bin/ on the command line -- not yuno.pid, which a yuno writes where its own config says) and skips it with a WARNING naming its pids (“yuno alive but not connected to the agent: not launched again”); a run-yuno that finds only such yunos says so. A node bounce (restart_nodes(), deactivate-snap) kills them too, SIGKILL with a WARNING, before it runs them all again. kill-yuno still acts only on yunos with an open channel. Also: a yuno whose pid file cannot be written logs it, instead of a SegFault in fprintf(). (no red test; checked on the local agent: two yunos stopped by SIGSTOP across a restart of the agent were not launched again, the WARNING named their pids, and they reconnected on their own when resumed)

• Docs: kill -9 on a yuno’s child ends it for good. ENTRY_POINT.md §7 and YUNO_LIFECYCLE.md §5.3 said the watcher relaunches a child killed by SIGKILL; it exits on it (ydaemon.c, as the table of ENTRY_POINT.md says). Any other signal is a crash and is relaunched.

• mbedTLS: a failed output callback no longer frees its gbuffer twice. The gbuffer is the callback’s whatever it answers, and C_TCP’s releases it with the kw of EV_SEND_ENCRYPTED_DATA on every path; the backend released it again (a C_TCP that refused the output, in ST_WAIT_STOPPED with its TLS session alive). OpenSSL ignored the answer: it now logs it. The ownership is written in ytls.h. (no red test: found by reading)

The reborn key of an rt_disk follower (the HIGH open since 7.25.20)¶

• An rt_disk follower behind a master in another process no longer hands a key’s later life before its delete. It took the link of a new record and read the key’s files BY PATH, so after the master deleted the key and wrote it again, a late event of the old key directory consumed the NEW life’s link and read it against the old life’s cache: [R2 DEL], the live key out of the cache, the next append handing R1..R4. The identity check of 7.25.21 (inode and birth) could not tell the directories apart on the nodes: ext4 on Debian’s 6.x kernels gives a directory made again the inode and the birth time of the old one, and test_delete_key_propagation (“race in the batch”) failed there 9 runs in 10. Now each key directory is watched with a descriptor of its own, the very inode of its watch (new FS_FLAG_DIR_FDS and fs_watcher_dir_fd() in fs_watcher, new event_wd/subdir_wd on every event); a link is taken through the descriptor of the directory its event came from (openat/unlinkat), and its records are read through descriptors checked to be the link’s life. Under a random load of a master in another process (appends, deletes, rewrites 0-20 us apart, a follower slowed 0-100 us a record, 3 feeds and 4 keys), 7 to 11 of the 12 feed and key pairs got a life out of order; none now, on the dev kernel and on wattyzer’s 6.12, and the last life of every key is heard whole. Cost: none on the append path (22.4 us a record and feed, both), +5% on the 69632-key flood of test_rt_disk_overflow (18.1 -> 19.0 s, an open and a watch through /proc per new key directory). Tests test_delete_key_propagation (new “a stale link”, fails on the code before it locally too: [R2 DEL]; “race in the batch” passes 30 in 30 on wattyzer, 1 in 10 before) and test_fs_watcher_overflow (new “dir fds”).

• Out of descriptors, that read no longer uses memory freed or a descriptor closed. The check of a life borrowed its record of what was checked, then opened the content: out of descriptors, that open closes every read descriptor, the md2 just checked and that record too, and the check wrote into the freed record and handed the md2’s number, by then the content’s, to be read as md2 rows. The md2 is now looked for again after the open: closed, the check starts again, once; a second time, the records are not read, with an ERROR. (no red test: found by reading)

• A link consumed already is not read again by path. The scan of a key directory and the link’s own event can both meet a link; the second one found it gone and read the key’s files by path, which is the race this section fixes (a new life read against the old one’s cache) and re-read what the first one had read, or had left unread for being another life. The first one unlinks and THEN reads, so nothing is lost: a record made later makes a new link. (no red test: a window of microseconds)

• fs_watcher: a watch that cannot be made is said as what it is. A failure of the watch through /proc/self/fd was always taken for a missing /proc, said once per process and retried by path; with no watches left (ENOSPC, ENOMEM) that spent the only /proc message and a second watch. Those two now fail at once with their own ERROR. The test “dir fds” now checks that no descriptor is left open after the stop.

Risks the review named¶

• timeranger2: a delete no longer walks every open key. To close the descriptors of the deleted key, the master (at tranger2_delete_key()) and each follower feed that heard it walked every key with an open file. With 50000 keys open, 2000 deletes and 4 feeds: the master 9.2 s -> 0.17 s, the follower 4.3 ms -> 17 us per delete and feed. What stays is linear in the feeds (fs_queued_events_end() per other feed, to note what each one owes): 17 us per delete and feed with one feed, 30 with sixteen; it was measured and kept, a mark taken once per batch could make a debt be forgotten unpaid. (no red test: a benchmark, figures above)

• C_TCP: a stop waits timeout_stop_tx at most for a write in flight. A peer that does not read (a window of zero) held the write, the stop of the connection, and so a C_TCP_S stopped and started again: its clisrv waited in ST_WAIT_STOPPED for ever and the server never listened again. The socket gets a TCP_USER_TIMEOUT when the stop has to wait for a write. Test test_c_tcp_s_stats.

• C_TCP_S: a server of the new method leaves to another running one the channels it serves, with an ERROR naming it; it took them all, silently (they accepted on its socket, the other server accepted nobody, and its stop and its counts missed them). Test test_c_tcp_s_stats.

• SECURITY: the agent’s audit record redacts a name with a secret’s part whatever else it holds (new is_secret_name_any()): api_key_max, token_mode, secret_type were written in clear, being names ABOUT a credential for is_secret_name(). Test test_audit_record.

• SECURITY: the subscription traces mask their __filter__ / __config__ / __global__. The traces of a subscribe, of an unsubscribe and of the filter at a publish (subscriptions / ev_kw / machine) printed a credential in them as it was. Test secret_attrs.

• timeranger2: a filesystem with no birth time is said (a WARNING, once per process): the identity of a key directory is then its inode alone, and a key deleted and written again can take the freed inode. (no red test: needs such a filesystem)

• timeranger2: the note of a deferred key directory scan fits its numbers (it held 96 bytes for up to 105), and a truncation would be an ERROR. (no red test: unreachable now)

• Traffic dumps: the masking of received bytes is per buffer, documented with an example: a credential cut between two reads shows in the second dump. What we send is marked secret at its source and never dumped.

v7.25.21 (2026-10-01)¶

What changed after 7.25.20. Each behaviour change has a test that fails on the code before it, except the few this list marks “(no red test)”.

Upgrade steps (operators, read first)¶

• Nodes that build from source: rebuild the external libraries first. linux-ext-libs is 1.23 (openresty now comes from its release tarball; no library changes version): run cd kernel/c/linux-ext-libs && ./extrae.sh && ./configure-libs.sh, then yunetas clean && yunetas build (it refuses to build until then).

• Rebuild every project against the new headers. gbuffer_t gained a field (secret) in the middle of a public struct whose accessors are inline: an object built against the 7.25.20 headers reads the wrong fields.

• Deploy gui_agent 0.29.7 before, or together with, the agent and the control center. The agent now answers a watch-yuno-stats only to a requester that says it takes EV_YUNO_STATS (__relays__), and the control center passes that on only when its client says so. An older gui_agent is refused the watch, directly and through a control center: it still works, polling the stats instead, with one warning per node in the browser console. gui_agent 0.29.7 and gobj-js 7.25.9 work with the 7.25.20 agents too.

• A host of C_FS must not subscribe to it by hand any more. C_FS now subscribes its parent (or its subscriber attr), as every child gclass does; a host that still calls gobj_subscribe_event() on it gets “subscription(s) REPEATED, will be deleted and override”. watchfs is updated. A C_FS with recursive: false no longer reports subdirectories.

• emailsender stops (exit 0, not relaunched) when the SMTP server refuses this client, like refused credentials: a 5xx to the greeting (the 554 of a provider that blocked the address) or to EHLO, and a second 334 to AUTH PLAIN (the first is answered once, as RFC 4954 allows). Every further attempt would be one more refused login in the provider’s logs. Fix the cause and run the yuno again.

• Send a test email after upgrading emailsender, and after set-email-user. It no longer logs in at start, so wrong credentials or a server that refuses this client are found at the first email, which then stops the yuno (exit 0, not relaunched).

• The agent needs write permission on each yuno’s bin/: a config file is now written to a temporary file there and renamed over the old one. The files are 0640: a reader outside the group of the agent’s user loses access.

• emailsender’s failed queue fills much later. A server that fails its handshake no longer sends the head of the queue there every 8 s or so, one message after another: the messages wait at the head of the queue, paced up to 10 minutes between attempts, for as long as the outage lasts (a refused default sender for up to max_retries paced attempts), and one that refuses every message is paced from its third refusal in a row. An alarm on the size of the failed queue sees that change. A stuck head of the queue can be moved there by hand with the new skip-email.

• A lone stop of a C_TCP_S without child_tree_filter closes its live connections (it kept them accepting on a closed socket): to drain a listener, do not stop it alone.

• emailsender says when its SMTP server fails: a WARNING at the first failure, an ERROR once it has failed for timeout_failing_alarm (1 h), an INFO when it works again. An alarm on its ERRORs sees the new one.

• C_TCP_S connxs and tconnxs read real values (they always read 0); a dashboard that showed them changes.

Performance, against 7.25.20¶

• The report of this release measures it against 7.25.20, the release of the last report: performance/reports/7.25.21.html, and the trend on doc.yuneta.io/performance. Both releases built whole, run alternately, 8 rounds (24 for the timeranger2 tests).

• Nothing slower beyond its noise: the masking of secrets runs only when a trace prints, a secret gbuffer costs one flag test, and a TCP send one key lookup. Appends 223,031 -> 225,883 per second (+1.3%, noise).

• Three figures moved outside their spread, all faster, and none is claimed: the gobj TCP echo +4.8%, the BFF logins +3.1%, 600 000 appends to one key -3.7% of time. No change takes work off those paths (the append code is the same as in 7.25.20): placement of whole-release builds.

• The static binaries are 0.6-0.9% larger (stripped).

SECURITY: secrets that still reached a reader or a log¶

• SDF_SECRET on the credentials that were not flagged. C_IEVENT_SRV.http_cookie holds the browser’s whole Cookie header, the BFF’s httpOnly access_token included, and view-gobj, view-gobj-tree and view-attrs showed it for every connected browser. It is now masked, as are the MQTT 5 auth_data of C_PROT_MQTT2/C_PROT_MQTT, webstats visitor_salt, the esp32 transport’s jwt and C_ESP_WIFI’s wifi_list. (Each flag is a declaration; the masking it drives has red tests, http_cookie and auth_data too.)

• A secret is masked whatever its json type. gobj_mask_secret_attrs() and view-attrs of one attribute masked only non-empty strings, so "pin": 1234 was shown. Only an absent value or an empty string stays. gobj_mask_secret_attrs() now logs an ERROR and returns -1 for a NULL gobj or attrs that are not a dict (it returned 0 in silence).

• view-config masks the secrets. It dumped the config as it is, so a password or client_secret in a service’s kw, a child’s kw or a global key reached whoever asked. The new gobj_mask_secret_config() masks, on a copy, every value that lands on an SDF_SECRET attr, of any json type; a global key named by a gobj that is not a service, or of an unknown gclass, is masked when its attr is SDF_SECRET in any gclass; and a __json_config_variables__ entry is masked when it feeds a secret or has a secret’s name. The [^^children^^] template of a service is masked too (its __content__ as a node, its __vars__ as config variables), here and in the create_delete2 traces.

• Command parameters can be SDF_SECRET, and a trace masks every key with a secret’s name. The commands trace printed the command line, and with ev_kw the command kw, in clear: passwords given to set-user-pwd, create-user, set-email-user, and through the agent’s command-yuno ... password=X, whose free kw no table describes. A parameter declared SDF_SECRET, and any key named like a secret (is_secret_name(), new in helpers.h: the one list of the SDK, which the agent’s audit uses too), is shown as ******** in all three traces (new command_mask_secret_kw() / command_mask_secret_line()), as is the value of a write-attr of a secret attr. A positional secret that holds a = is masked, and a part of the line that cannot be parsed is shown as <...> instead of being dropped, and a quoted value keeps its closing quote. The parser’s error answers no longer echo a secret (a plain extra word is still named; any text after a secret parameter is masked whole). A parsed key containing a blank (password= hunter2 x=1 reads the key hunter2 x) refuses the command and is not echoed; an SDF_WILD_CMD command took it as a free key. Flagged: C_AUTHZ password, C_IDP_KEYCLOAK kc_admin_client_secret, ycli user_passw, C_PROT_MQTT create-user password, emailsender set-email-user password (a red test covers the last; the others are the same one-word declaration).

• Every kw the kernel dumps on an error or in a trace masks the credentials. The kw_get_*() errors (“path MUST BE a json str” with the whole kw, so a password read with the wrong reader landed in an ERROR log), the machine trace with ev_kw, the authz traces, “No subscription found”, “Publish event WITHOUT subscribers”, and the ievents / ievents2 traces of C_IEVENT_CLI/C_IEVENT_SRV, which printed a command’s password in clear both ways. They go through the new gobj_trace_json_masked() (json_mask_secrets(), mask_secrets_inline()): a key with a secret’s name is masked at any depth (down to 64 levels, a dict met twice the same everywhere, a cycle as "<cycle>") and of any type, and so is a name=value credential inside a string (an unquoted secret value runs to the next word=, so a password written with blanks is masked whole; a quote inside a value is part of it); the 64 levels count from the first time a shared object is met; a name that only describes something about a credential (token_endpoint, cookie_domain, jwt_public_keys, *_count) is not. The ievents traces also use the command table of the destination service when it is local. gobj-js 7.25.9 masks its traces the same way. With gbuffers the kw’s gbuffer is dumped, masked (a secret gbuffer as hidden, one that parses as json through the same masking). Masking is linear and bounded, because a peer reaches it before its session (the dump of the kw of an event before the identity card). A name is the word before the =, judged by its last 128 bytes. Every json node walked costs one unit of the budget, a key or a string its bytes too: 4 MB per json_mask_secrets() call, or max_bytes for the new json_mask_secrets_capped(). Once the budget is spent the walk stops and one “” stands for the rest of each container; a text over 4 MB, or one whose masked copy cannot be allocated, is that placeholder too, never shown in clear. The work is bounded by the cap, not by what was sent. C_IEVENT_SRV caps that dump at four times the 256 bytes it shows. gobj-js masks with the same bounds.

• The traffic dumps mask the credentials they can recognise, received data included. No sender can mark what it receives, so the traffic trace of a server gate printed a browser’s Cookie header or a form password in clear. gobj_trace_dump*() now dump through the new mask_secrets_in_text(), which writes * over the value of an HTTP Cookie, Set-Cookie, Authorization or Proxy-Authorization header, of a secret name=value and of a json "name": value with a secret’s name (a list or a dict up to its closing bracket), keeps the length, and says "masked": N (gobj_trace_dump() gives {"len", "masked", "data"}). A secret in received bytes that fits none of these is still dumped as it came.

• The create_delete2 trace no longer prints secrets: its kw and sdata dumps showed the passwords a gobj is built with (the smtp child’s, ycommand’s user_passw).

• Secret gbuffers: hidden from the traffic trace, wiped on free, never serialized. The C_TCP traffic trace dumps outgoing bytes before TLS, so a credential sent as data -- the SMTP AUTH line -- reached the log. New gbuffer_set_secret() / gbuffer_is_secret(): every trace dump prints a secret gbuffer as <N bytes hidden>, and it is zeroed when freed or grown; gbuffer_append_gbuf() flags its destination before it copies. C_TCP takes "__secret__": true in the EV_TX_DATA kw, and the flag survives the tx queue. A secret gbuffer is not serialized: gbuffer_serialize() answers NULL (logged), and a kw carrying it crosses without it. The emailsender marks its AUTH line.

• The persistent-attrs file is written to a new 0600 file and renamed over the old one. It was truncated and written in place, into whatever inode the name had (another user’s file, a hard link), and a password set once and never saved again stayed in a 0664 file. A save now writes <file>.tmp-XXXXXX (0600), renames it and syncs the directory; a failed save leaves the old file as it was, and a link in its place is replaced, with nothing written through it. A readable file of another user is taken over by the yuno’s user (logged at INFO); when the yuno runs as root, the new file is given back to the old owner (no red test for these two: a non-root test cannot make a file of another user). A file that cannot be read refuses the save and the removal (its attrs would be lost); an empty file is no data. A file of the yuno’s own found at load that is wider than 0600 or a hard link is replaced the same way (not narrowed in place, which through a hard link changed another name). In a data directory the yuno cannot write, the save goes in place, into a file of its own only: room is reserved without growing the file, so a full disk leaves the old file as it was where the filesystem can reserve it (not on NFSv3/FUSE without fallocate, nor on copy-on-write filesystems), but a crash or a short write there can leave an unparsable file, which then refuses the saves until it is removed or repaired (the message says how). A <file>.tmp-XXXXXX an interrupted save left is removed at the next load. write-attr answers a failed save with -1 (“written, but NOT saved”) instead of “done”, and says “NOT persisted” for an attr of a gobj that is not a service.

• A yuno’s materialised config files are 0640, never world-readable. The agent wrote bin/<n>-<role>^<name>.json, which carries the yuno’s secrets, as 0664, and an existing file kept its old mode. Each is now written to a temporary 0640 file in bin/ and renamed over the old one, so a file of another owner or a symbolic link is replaced, not truncated and then refused, nor followed, and a failed write leaves the old file whole. Files an earlier launch left behind are narrowed, and the temporary files of an interrupted write are removed (logged).

• The agent’s audit never writes a peer field raw when it cannot redact it. A failed allocation inside the redaction wrote the JWT or password= it was meant to hide, or 4 KB never scanned. It now writes <not written: no memory to redact it> and logs it. A peer field that is not UTF-8 is a warning, not an internal error.

• C_IEVENT_SRV: the dump of a peer’s kw before its session hides every credential, at any depth and of any type, and name=value credentials in a command line (it dumped the whole kw through trace_inter_event).

• MQTT: the CONNECT decode trace no longer prints the password, and prints the username by its length (it read past a field that is not NUL-terminated, so a long password also appeared on the username line). The same over-read is fixed in the SUBSCRIBE/UNSUBSCRIBE traces and the “invalid will topic” warning. The dump of a refused CONNECT no longer carries the credentials: a CONNECT with one extra byte after a valid password put the password in the log; of a CONNECT only the protocol name, level, flags and keep alive are dumped now, of an AUTH only its reason code.

• A value with no closing quote refuses the command. password='abc with no closing quote dropped the parameter, and the command ran without it and with no log. It is refused now (“value with no closing quote”), naming only the key.

Kernel¶

• A renamed subscription is no longer a repeat of a plain one, nor of another rename. Since 7.25.5, subscribing EV_X with __rename_event_name__ found an existing plain EV_X subscription of the same subscriber as REPEATED and replaced it, and two renames of one event collapsed into one (withdrawing either removed both). The renamed event is part of the match now. A kw with no rename is still a wildcard, so a plain subscription made over a renamed one replaces it, and a plain unsubscribe removes both (see publish.md). gobj-js 7.25.9 renames as C does.

• gobj_unsubscribe_list() removes the subscription it is given, not the first one that looks like it. A stale plain subscription (already removed) removed a live one, e.g. one with a __filter__. The object itself is looked up; one no longer there removes nothing, is not passed to mt_subscription_deleted(), and gives one warning per call (“Subscription(s) already removed, nothing to remove”), and one withdrawn by mt_subscription_deleted() meanwhile is not taken for a hard one kept.

• A subscription the publisher refuses leaks nothing. When mt_subscription_added() answered -1, gobj_subscribe_event() removed it but never dropped its creation reference: each refusal (a subscription C_IEVENT_CLI could not send to its peer) leaked one.

• A subscription list that outlives its publisher is safe. _delete_subscription() read the publisher out of the subscription it was given, freed memory once the publisher was destroyed (a list from gobj_find_subscriptions() keeps the subscriptions alive). A removed subscription now has its publisher and subscriber set to 0, and such a list removes nothing. A subscription removed during a publication is no longer delivered from the copy being iterated.

• C_IEVENT_SRV: an identity card it refuses is the peer’s, one capped warning. Before the session, a card with no routing, for another role/yuno/service, or with no src role/service was an ERROR with the whole kw (jwt included), plus a second ERROR “event UNKNOWN in not-session state”. Each is now one warning (protocol category, peername, kw capped, credentials hidden) and the channel is closed. A jwt that is not a string is refused instead of authenticated, and an event before the card gets one warning.

• C_TCP_S: connxs and tconnxs count the connections. Both always read 0: connxs was never decremented, and servers without child_tree_filter never saw their accepts. Now they are the connections held and those accepted since the gobj was created (a stop and a start do not reset it), for both accept methods, as attrs and in stats, and a connection counts for the server whose clisrv it is (new C_TCP attr tcp_s), so two servers sharing channels and a port on two hosts do not count each other’s. C_TCP’s own connxs is readable too. The clisrv names stay unique across restarts.

• C_TCP_S: a stop and a start in the same turn listen again. The start made a second socket while the first was still being cancelled; its bind failed and, by default, the yuno exited. It now waits in ST_WAIT_STOPPED and listens when the stop ends.

• C_TCP_S: a TLS server started again keeps its ytls and reloads its certificates. Each start freed the ytls and made a new one, while the connections that outlived the stop (child_tree_filter) still used it: the next record of such a connection was decrypted with freed memory. A restart now applies the new certificates to new connections, as reload-certs does, and live connections keep theirs until they close. It reloads only when the crypto config (trace_tls included) or one of its files changed (inode, size, mtime, ctime), so a pause and a play no longer log “TLS certificates reloaded” each time; a failed reload is still an ERROR, and an update of the system CA bundle (ssl_use_system_ca) needs reload-certs.

• C_TCP_S: a lone stop of a server without child_tree_filter stops its clisrvs. They kept accepting on the closed socket, and the next start logged “GObj ALREADY RUNNING” for each one. In that method the clisrvs are its connections, so a lone stop now closes its live connections: a host or an operator that stops only the listener to drain it (disable-gobj of the listener, gobj_stop() of the C_TCP_S alone) closes its sessions instead of keeping them. With child_tree_filter the connections still survive a stop of the listener.

• C_TCP: a clisrv of the new accept method started again leaks nothing and waits for its accept in ST_DISCONNECTED. Its start created a new accept event over the one of its last start, never destroyed (a leak, and “Destroying a running event” at shutdown), and it stayed in ST_STOPPED, so its next stop never cancelled the accept, which kept the port bound.

• yev_loop: freeing a duplicated accept event no longer closes the listener’s socket. It closed that socket number, and took back the submissions on it, even when the number had been reused by then.

• C_IOGATE: “send to all” delivers the whole message on every channel. With send_type 1 (or __send_type__ 1) a message in a gbuffer was shared by all the channels: the first read it out and the others sent an empty frame, on which a C_PROT_TCP4H peer drops the connection. Each channel but the last now gets its own copy (with the secret flag, label and address), and the last takes the original.

• C_TCP: data sent while a connection closes is said once, with its count, on every end of the close, destroy included. It was dropped with no trace at the default levels; now one warning per connection gives the messages and bytes dropped.

• C_TCP: connect_on_start lets the owner make the first connection on demand; disconnect_cause says why a connection ended (new attributes). connect_on_start false keeps a client in ST_DISCONNECTED at its start until its owner sends EV_CONNECT. Only that first connection waits: after an end the client reconnects after timeout_between_connections unless that is -1, which makes every connection on demand. disconnect_cause keeps the FIRST cause of an end (the read cancel a drop or an inactivity close makes does not replace it): the socket error, a TLS failure with its reason, “Local dropping”, “Inactivity timeout”, “Local stop”, or a write or connect that could not start. It is emptied when a connection begins, a clisrv’s included, and the Disconnected trace shows it as its cause. (no red test for the TLS and fault-injection causes)

• C_TCP: an EV_CONNECT cancels the pending reconnect timer, so a connect on demand no longer gets a stray EV_TIMEOUT in ST_WAIT_CONNECTED.

• C_GSS_UDP_S starts its C_UDP_S again when it stops by itself. The service stayed deaf and every send logged “Event NOT DEFINED in state”. The stop is said once. A send is refused (one warning per stop, the count at the restart or at the stop) whenever the C_UDP_S is not in ST_IDLE, including while it is still stopping. The C_UDP_S restarts after a backoff: timeout_base first, doubling up to 5 minutes while a try does not hold a minute, and a failed start takes the same path. A C_UDP_S stopped from outside is not restarted. A timeout_base <= 0 is refused with a warning and 5000 is used. A stop and a start in the same turn (logcenter’s pause and play, with a read in flight) found the C_UDP_S still holding its socket: an ERROR, and the service never received again. The start now waits for the C_UDP_S to end its stop.

• A build with mbedTLS compiles again. C_ASSETS included <mbedtls/md5.h>, which mbedTLS 4 moved under mbedtls/private/, even when OpenSSL was compiled in too: any .config with CONFIG_HAVE_MBEDTLS failed to build. On mbedTLS the md5 of a signed url is now psa_hash_compute().

• Static resolver: v4-mapped literals answered as glibc answers them. “127.0.0.1” in AF_INET6 with AI_V4MAPPED returns ::ffff:127.0.0.1, and “::ffff:1.2.3.4” in AF_INET returns 1.2.3.4; both were EAI_ADDRFAMILY. An IPv4 literal is numeric in every form glibc takes: "127.1", "10.1.2", "0x7f.1", "0177.0.0.1" and "2130706433" went to DNS, and AI_NUMERICHOST refused them; a blank around a literal still makes it a name.

• C_FS publishes by the value of the event type, watches the tree once, recursively only when asked, and subscribes its parent. The fs_watcher types are values, not bits: a deleted directory published nothing and leaked its kw, and other types published by accident. A recursive C_FS also added a recursive watcher per subdirectory, so a change N levels down was published N+1 times, and "recursive": 0 reported the subdirectories anyway. Now one watcher on the root, recursive only with recursive set. It subscribed nobody (its host had to do it by hand); it follows the CHILD model now, with a subscriber attr. size_dl_watch reads 1 while watching, 0 otherwise. A watcher that cannot be created, or whose read cannot be armed, fails the start (it answered 0 with nothing watched; the second case has no red test).

timeranger2 and its tools¶

• A feed that overflowed hears the deletes another feed of its topic heard, and hears each delete once. The feeds of a follower share the topic’s cache, and the first to hear a key-delete removed the key from it; a feed whose inotify queue overflowed then compared the cache with keys/, found nothing gone, and never got its key_deleted. Each feed now keeps the deletes it still owes. A delete signal queued behind the overflow marker, for a key the overflow already reported, is not reported again (it fired key_deleted twice, also with a single feed); every event of a watcher has its position in the watcher’s stream (fs_event->offset), and fs_queued_events_end() says where the events queued so far end, a read that the kernel completed and the loop has not delivered included (new yev_get_waiting_completion()). A feed that starts watching after a delete was signalled does not owe it. A debt is forgotten by a record of the key that reaches the feed in its place in the stream: a link heard in the feed’s directory, or a record found by the deferred read of a key directory (see the reborn-key bullet below). In a master, hearing a delete makes no debts; tranger2_delete_key() makes them.

• A key deleted and written again (once or more) before a follower reads the delete is handed right in far more cases, for any key, one the follower never saw included (with the master in another process and the follower lagging, a race remains: an open defect, see TODO.md): the feed is told deleted (once or more), then the records of the key’s last life from rowid 1, and the key stays in the cache; records of a life deleted before the follower read them are not handed. A follower reads a key directory only if it is still the directory it looked at before it asked where its queue ends, and only once its stream is past that point (each event carries its offset_end; new FS_FLAG_BATCH_END / FS_BATCH_END_TYPE); a file linked in a directory that waits to be read is read with it, in order; on a delete the follower closes its descriptors on the key’s files. A record found then forgets the debts made before the directory appeared; a feed opened while a delete is in flight, and signalled after it was watched, no longer takes that delete as new; a delete owed at an overflow whose key is back on disk is paid, not taken as new. Before: a directory read too early ([R1 DEL], [DEL R1 DEL], the live key out of the cache, the same after an overflow), a second file of a new key first ([R1 R1]), a feed made to owe a delete again ([DEL DEL] at its next overflow), and a key read before, deleted and written again in the same day file, read through the old file’s descriptor (short reads, CRITICAL, lost records). An fs_watcher read takes up to 32 events; the 69632-key overflow flood drains ~7% slower (one more statx per key).

• fs_watcher: a root that cannot be watched gives no watcher (logged): with max_user_watches used up, or no permission, the watcher ran watching nothing.

• Only the first feed to hear a key-delete forgets the key (the shared cache, its segments, the watermark of every feed). Every feed did it, so a slow feed hearing an old delete after the key came back removed the live key from the cache and dropped its fresh watermark.

• In a master, the watcher’s echo of a key-delete no longer removes the key: a key the master wrote again before the echo came was dropped from its cache. tranger2_delete_key() has already removed it; the echo only calls the feed’s callback. And a master’s own rt_disk feed whose inotify queue overflows is told the deletes it lost: tranger2_delete_key() makes the debts for the master’s watched feeds, whose cache cannot show a lost delete.

• A watcher whose read fails is logged and tells its owner before it goes (FS_WATCHER_GONE_TYPE). It went silently, and a timeranger2 feed later used, and stopped, the freed watcher. Its owners now drop it and say they are deaf: the rt_disk feeds, the master’s watch of disks/, C_FS and utils/c/fs_watcher. So does a read canceled by someone other than its owner (an ordering bug: no shutdown does it, the owners stop first), and a read that cannot be armed again; a watcher its owner stopped still goes silently. timeranger2 checks the start of its watchers (a failed start is logged and no watcher is kept), and utils/c/fs_watcher exits with an error when its watcher is gone. (no red test for the read that cannot be armed, the start checks and utils/c/fs_watcher: none of them can be forced)

• A key-delete reaches only the feeds whose rkey matches the key. Lists, iterators and the rt_mem and rt_disk feeds use the same filter as their records; only key was checked, so a feed with an rkey was told that every key of the topic was deleted.

• A directory deleted and recreated during an inotify overflow is watched again, and so is the watched root. Its IN_DELETE_SELF and IN_IGNORED were lost with the overflow, the table kept the dead wd, and the rescan took the path as watched; a root reborn so went deaf, recursive or not. IN_IGNORED now clears its wd, and the rescan re-adds every watch, the root’s included.

• No rescan pass for a watcher its owner stopped on overflow.

• The keys listing names the call that failed: “lstat() FAILED”, not “stat() FAILED”.

• tr2check resolves the topic path, and never gives a verdict on a partial load. A relative db/topic or a bare topic opened the wrong directory; a key whose sequences could not all be kept in memory ended its load silently and could still PASS (now exit 2). The open-files limit raises the soft limit up to the hard one, and never the hard limit, root included; it says when it cannot.

MQTT¶

• A client’s wrong ack is a WARNING, not an ERROR. A PUBREC for a QoS 1 message (“QoS mismatch”) and a PUBREL for a packet id with no QoS 2 message waiting (“Message not found”, with a stack) were ERRORs naming neither the client nor the peer. Both are WARNINGs with client_id and peername; the broker still answers DISCONNECT 0x82 and PUBCOMP. As a client, a PUBREC for an unknown packet id is only the caller’s WARNING (it was also an ERROR with a stack).

• C_PROT_MQTT (deprecated): an UNSUBSCRIBE of several topics removes the topics sent. Each topic was read as a C string inside the packet and ran into the next one. The same gclass stopped logging a WARNING on every connection (an undeclared connected attr) and an ERROR for every absent MQTT 5 property, and its logs print the command as a string (twelve used "%d" on a const char *; no red test for those twelve).

Agent¶

• watch-yuno-stats trusts only the routing hop it can, and every requester must opt in. The watch was named from the last hop of the ievent stack, which the client writes, so a forged hop could stop or replace another user’s watch; it is now named from the agent’s own hop, or the control center’s (with cc_connection). A direct ycommand watch was sent events it cannot handle (“Event NOT DEFINED” until the watch expired): every requester must now send __relays__: ["EV_YUNO_STATS"] (gui_agent 0.29.7 does, directly and through the control center). The first readings follow the answer and go to the renewed watch only. New max_watch_ids (256) caps one watch; a cap under 1 refuses every watch and is logged once per bad value.

Control center¶

• What only an agent sends is taken only from the agents’ side. The answers of command-agent/stats-agent, the console PTY (EV_TTY_OPEN/DATA/CLOSE) and EV_YUNO_STATS are public events; a web client could send them too, with a route it wrote, and push answers, console frames or readings to another client’s channel. They are accepted only from __input_side__; one sent by a web client is warned about once a minute (with dropped=), not once per event.

• An agent’s answer goes only to who asked. When the route named no web client, the answer went to a service named by the client’s own hop: any local service that listens, and never the right one, so a command-agent made through the control center’s link to its own agent lost its answers. The requester is now the control center’s own hop: a __top_side__ channel, or its C_IEVENT_CLI link to its own agent, and only for an agent that link sent a request to. Anything else is dropped with a warning (PTY frames: once a minute). A command-agent answers at once “Command sent to 1 nodes”; the node’s answer comes later (ycommand -w <s> waits for it).

• command-agent says a client takes EV_YUNO_STATS only when the client says so. It wrote __relays__: ["EV_YUNO_STATS"] for every client, so a ycommand ... command-agent cmd2agent="watch-yuno-stats ..." was sent readings it logs as “Event NOT DEFINED”. It passes the marker on only when the client’s own __relays__ names it.

• Every answer and stream an agent sends back checks the web client’s connection, not only the stats: a slow answer or a console stream of a client that had left reached the next client of that channel. ac_tty_mirror_open also stored the client name from a freed frame.

• What a capped warning counted is said when its window ends, or when the control center stops (when=, dropped=), never per connection close, which a client could loop; a count with no later event after it was never logged. The window is the new drops_warning_window (ms, default 60000) of every capped warning of the control center.

• Stopping the control center outside the shutdown no longer logs “GObj NOT RUNNING”: mt_stop() stopped timers that clear_timeout() or mt_pause() had already stopped (an ERROR with a stack each).

• The message counters and rates count what it relays again. rxMsgs/txMsgs, rxMsgsec/txMsgsec and their maxima always read 0: nothing incremented the counters, and the 1 s tick that computed the rates was never armed. They count, once each way, a client’s command-agent, stats-agent, write-tty and run-scenario, each request and run step sent to an agent, and each answer or stream relayed to the client, the run’s answer included. The rate is computed each timeout (1000 ms) over the exact interval since the previous tick, so a reading is the same whoever reads and however often; the maxima keep the highest tick, bursts nobody read included; stats=__reset__ zeroes them all.

• Several console mirrors through one agent’s connection: the clients are kept per console; when the agent goes, each is dropped once.

• A run’s step is answered only by the agent it went to. A client with command-agent could put cc_run/cc_step in its own command and end or advance another user’s run.

• A step may not carry a framework key, and every run checks its steps again. __md_iev__=x in a step replaced the routing of its answer (the run waited for run_step_timeout), __username__= the stamped user, and a scenario saved by 7.25.14 skipped every step check. gui_agent refuses the same steps, naming the same parameter.

• save-scenario named a scenario it had freed in its answer, when the scenario came as a string.

• A step an agent does not answer in time is a warning, not an error. (no red test)

emailsender and webstats¶

• emailsender: a pause or a shutdown with a message in flight loses nothing and frees nothing twice. The yuno kept a pointer to the queued message the pause had freed, and the close that came after it read it (a crash at kill-yuno); the smtp session’s held message survived the stop and could be sent twice. A play right after a pause no longer fails on a closing C_TCP (“Initial wrong tcp state”), and it sends what the pause left queued.

• emailsender: a message the session refuses is resolved once. A message with no valid recipient (to="," through EV_SEND_EMAIL) was answered and also returned as a failure, so it was resolved twice, the second time on freed memory. It goes to the failed queue with no retry spent.

• emailsender: no failure is retried faster than the paced schedule. After any failed session or connection the next connection waits timeout_retry (2 s), doubled per failure in a row up to timeout_retry_max (10 min): a 4xx refusal, a 4xx or 421 to the end of DATA, a refused default sender, a reply that never comes, a connect or TLS handshake that does not end within timeout_response, a server that closes by itself, a refused or timed-out connect. An email queued during the wait waits too, and so does a pause and a play. A session that ends with no failure resets the doubling. The C_TCP never connects by itself any more, not even at the start (new connect_on_start): every connection is the session’s, made when it holds a message, and a yuno with an empty queue logs in to nobody. The doubling counts every failure in a row and is not reset when a message goes to the failed queue (a message refused with a 5xx counts only from the third refusal in a row, see below): with the defaults the first failing message gets 2+4+8 s, the next 16 s and then 32+64+128 s, and from the fourth on 600 s between attempts. Every retry came after a fixed 2 s, and a 4xx at the end of DATA uploaded the message again at once, four times.

• emailsender: a failing SMTP server is said. The first failure of a streak is a WARNING with its cause (a refused connection included, which C_TCP logs only when traced, so a message could wait with nothing said); a streak longer than the new timeout_failing_alarm (1 h) is an ERROR, said again at most once per that period; the first delivery ends it with an INFO. A streak exists only while an email waits; one of failed connections and handshakes ends at the next handshake that works (“SMTP server answers again”), any streak at a session closed with no failure, and a url changed (set-url-from and a pause and play) resets the pacing.

• emailsender: a stalled connect or TLS handshake is dropped after timeout_response, said and paced: the email waited for ever and nothing was logged.

• emailsender: a failure before the mail transaction spends no retry. The transaction starts at the first RCPT TO. A server failing its handshake spent a retry every 2 s, sending the head of the queue to the failed queue in about 8 s, then the next; the message now waits at the head of the queue, paced, for as long as the trouble lasts (a refused default sender spends one retry per attempt). A transient refusal of the login (a 454 4.7.0) is retried: any reply but 235 to AUTH PLAIN was taken as rejected credentials, the yuno exited 0 and was not relaunched. Only a 5xx is a refusal now, and a second 334 (see the upgrade steps); EV_ON_CLOSE carries the server’s reply text (reply), and the AUTH buffers are wiped before they are freed (no red test for the wipe).

• emailsender: a message the server refuses with a 5xx no longer costs the next one a reconnection. A 5xx to RCPT TO, DATA or the end of DATA dropped the session, so the next message logged in again. The message now goes to the failed queue after one attempt and the session goes on (RSET; if RSET is refused, QUIT, and the next connection waits timeout_retry), for the first two refusals in a row. From the third, with no delivery between, the server is refusing the messages: each refusal still goes to the failed queue, but the next message is paced and “SMTP server refused the last messages in a row: each goes to the failed queue, the next ones are paced” is logged (refused_in_row), never the “emails are NOT being sent” ERROR. Every refusal counts, a bad address included, so a queue refused one by one never gets a login per message; a good email behind such a run waits the paced delay until the next delivery. A 5xx to one recipient of several no longer refuses the message: it goes to the others, each refused one a WARNING, and the “email sent” line says who got it (to/cc the accepted addresses, refused the refused ones, bcc only as bcc_count/refused_bcc_count). A 4xx (rate limit, greylist, 421) is still paced and retried.

• emailsender: a refused sender is judged by the reply. A MAIL FROM refusal is the message’s (to the failed queue once, with a WARNING naming the from) only when its sender is its own (not the default, compared ignoring case) and the reply is about the form or existence of that address: a 501, a 5.1.7, or a 5.1.8 / 553 saying the domain or address does not exist (553 5.1.8 <a@b>: Sender address rejected: Domain not found). Everything else is the account’s, whatever the from and whether or not the reply quotes the address (Postfix quotes it in every sender reject): any 5.7.x (a quota, access denied, not owned), a 5.1.8 that does not say the address does not exist, a 4xx, the default sender. These are paced and charged to the message as a retry per attempt, so at most one email goes to the failed queue per max_retries cycle, and a head stuck past timeout_failing_alarm raises the ERROR. Every attempt that ends in a refusal of a message sends it to the failed queue or spends a retry. Any 5xx to MAIL FROM sent every queued email to the failed queue in turn.

• emailsender: new command skip-email moves the email at the head of the queue, the one every other waits behind, to the failed queue at once (with a WARNING), and answers with its to and subject; it works while paused: ycommand -c 'command-yuno id=<id> service=emailsender command=skip-email'.

• emailsender: timeout_retry and timeout_response under 1000 ms, or timeout_retry_max under timeout_retry, are refused with an ERROR and the default taken (0 gave a tight loop, or a timer never armed).

• emailsender: a run of messages resolved at once is drained by a loop. A message refused inside its own send (no valid recipient, bad content) sent the next one from inside its own resolution, about 1 KB of stack per message: a persisted batch of some 9000 of them overflowed an 8 MB stack.

• emailsender: delivery is documented as at least once. A connection lost after the final “.” and before the 250 (or a 250 later than timeout_response) is a transaction failure: the message is sent again, so the recipient can get it twice. (Same behaviour as 7.25.20; no red test.)

• emailsender: an idle session closed by the server no longer logs in again with nothing to send (it did 2 s later, for ever with timeout_inactivity -1).

• emailsender: bytes read after the session decided to drop are ignored: a 250 read after the watchdog dropped the session resolved the message as sent, and the next MAIL FROM went on the dying connection. (no red test)

• emailsender: an email queued during the SMTP handshake waits for it; it was refused (“Event NOT DEFINED”) and retried in the same instant, spending all its retries before the server had greeted.

• emailsender: the send logs name the recipients and the url the message went to. They logged an empty to, after a refused send bytes from freed memory, and the new url after set-url-from while the running session still sent to the old one. They give to, cc and bcc_count (never the bcc addresses).

• emailsender: a session the SMTP server ends is a WARNING of C_SMTP_SESSION, with the reply capped at 512 bytes, and an over-long reply line is one WARNING, with no “gbuf FULL” ERROR before it. An ERROR of the session is our own failure; the emailsender’s ERRORs (moved to the failed queue, exit on refused login) are what an operator must act on.

• emailsender: set-email-user url= and set-url-from reach the SMTP session (it started on the old url); a running session takes the new url at its next start, and the answer says so. Every command answer names the yuno.

• webstats: the addresses a sentence dot, a port, ::ffff:, a colon or a dash left bare are bracketed ([a.b.c.d]., [a.b.c.d]:443, [::ffff:a.b.c.d], client:[a.b.c.d]), which could bring back the OVH “phone number” drop; an IPv6 literal that ends in an IPv4 is bracketed whole ([64:ff9b::a.b.c.d]). Versions and times are left as they are.

• webstats: yesterday is the calendar day before, not now - 86400, and a scheduled run reports the day before its slot, not before the moment the timer fired (spring and autumn DST days, report_hour 0).

• webstats: days are counted on the calendar, not as N*86400. The oldest day that keep_days keeps (the prune and the report-day refusal) and the age of a whois_cache_days answer were now - N*86400, one hour off per change of hour in between: near midnight the oldest day kept moved by one day twice a year, and a cached answer expired an hour early or late.

• webstats: a scheduled slot runs, and is mailed, once. A timer that fired before its slot, with a run that ended before it, armed the same slot again, and on the day of the autumn change a report_hour in the repeated hour ran twice. A slot is now judged by the day it reports, and each one is built from its date and report_hour (after the spring change a 02:30 stayed 03:30 the day after). The new stat next_run gives the time of the next run.

• webstats: a run that keeps the stored day publishes it, not the empty one it read.

gobj-js 7.25.9 and gui_agent 0.29.7¶

• gobj-js: the two subscription fixes above (renamed subscriptions, the subscription given), renames as in C (__original_event_name__, the renamed event is published), traces and logs mask credentials as C does (is_secret_name, json_mask_secrets, mask_secrets_inline, trace_json_masked in helpers.js; only json is walked: a gobj, a widget, a DOM node or a class instance is passed through, an object met twice is masked everywhere, a cycle is "<cycle>", and the masking never throws), and subs_flag carries the C bits. gobj_unsubscribe_list() of a subscription already removed gives one warning per call (“Subscription(s) already removed, nothing to remove”). Publishing costs the same as before (measured: 701 against 703 ns per delivery).

• gui_agent: a watch of the yuno stats says it takes EV_YUNO_STATS, directly and through a control center, and a scenario step may not carry a framework key.

Tooling and house rules¶

• linux-ext-libs 1.23: openresty from its release tarball. extrae.sh downloads it from openresty.org (sha256 pinned in repos2clone.sh as SHA256_OPENRESTY) instead of cloning the git repo. Building from the git tag ran util/mirror-tarballs, which fetches about 45 modules as tarballs from github.com, one download per module. The release tarball is the output of that step, with the same modules at the same versions, configured with the same flags, so the binary is built from the same sources.

• A SessionStart hook prepares a cloud container for the C suite and the JS packages (.claude/hooks/session-start.sh). It does nothing outside a cloud session.

• No two test binaries share a port, and the c_mqtt tests have a work dir of their own run. Ten ports were shared (7778 by the c_tcp/c_tcps families, 18801/18802 by the c_auth_bff binaries, 3333 by the yev_events tests, among others), so ctest -j failed with “bind() FAILED”; the new scripts/check_test_ports.py exits 1 when two binaries share one. Each c_mqtt test wiped a fixed /tmp/test_mqtt_<name> and left it behind; each run now makes its own and removes it.

• yunetas CLI 0.20.3: sync-binaries, sync-configs and set-start-priorities refuse an access_token that is not a string, a token answer or an OIDC discovery document that is not a json object, and a discovery that fails, with a clear error and exit 2 (Python raised TypeError, AttributeError or a traceback).

• search_process() (behind --stop) allocates through gbmem_* and no longer leaks the /proc/*/comm glob when an allocation fails. The executable-name check of entry_point.c takes gbmem_strdup() too. Both pairs were balanced (no heap mixing), but they bypassed the allocator’s limits and CONFIG_DEBUG_TRACK_MEMORY. (no red test)

• Braces on every body in c_authz.c, c_uart.c, c_websocket.c, run_command.c, c_yuno.c, entry_point.c and ydaemon.c, and // Error already logged after the gclass_create() of C_ASSETS, C_AUTH_BFF, C_PROT_RAW and C_PTY. They compile to the same machine code as before. (no red test)

• About 45 comments and test READMEs said what the code did “up to this fix” or “before this fix” without saying which release; each now names it.

Known limitations¶

• An rt_disk follower lagging behind a master in another process can still hand a key deleted and written again out of order (present since 7.25.20, narrowed by this release, not ended): it reads a key directory’s links by path, and on Debian’s 6.x kernels with ext4 a directory removed and made again can keep the same inode and birth time, so the identity check cannot tell them apart. timeranger2/test_delete_key_propagation (“race in the batch”) fails there for that reason and passes on newer kernels. The fix (reading through a descriptor of the watched directory) is planned; see TODO.md. Production masters feed their own lists from memory (rt_mem) and are not affected.

• A frame before the session is parsed whole, up to the maximum block (also in 7.25.20): an identity card is small, but nothing caps a frame sent before it. The masking of that frame is bounded since this release.

• The rest of the open items are in TODO.md, “Found by the last review before the merge” and “Defects open after 7.25.20”.

v7.25.20 (2026-09-30)¶

The last hole of the secret masking of 7.25.19, and the performance study of the fifteen releases since the last one (7.25.5): the report of this release measures 7.25.20 against 7.25.5.

Kernel: list-persistent-attrs masks the secrets too¶

• 7.25.19 masked SDF_SECRET attrs in view-attrs and the rest, but list-persistent-attrs (and the answer of remove-persistent-attrs) still showed them in clear: the mask was applied one level above the {<gobj>: {attrs}} it answers. gobj_list_persistent_attrs() masks each gobj’s attrs itself now; every caller of it shows what it answers.

Performance, against 7.25.5¶

• The report of this release measures it against 7.25.5, the release of the last report: performance/reports/7.25.20.html, and the trend on doc.yuneta.io/performance. Both releases built whole, run alternately, 8 rounds (24 for the timeranger2 tests).

• Faster, all from the SWITCHS fix of 7.25.7 (it compiled a regex on every entry): the open of 40 treedbs with an unchanged schema 0.667 -> 0.318 s (x2.1), a saved treedb update -25.2%, link/unlink -20.3%, the delete of a parent of 200 children -17.3%, an update in memory -16.2%, the first open of 40 treedbs -8.1%, a create -7.0%, appends with a live reader +12.8% (the benchmark’s callback uses SWITCHS).

• Nothing slower beyond its noise. tm_build_appends +3.6% (at the edge of the spread) runs the same append code in both releases: placement. test_topic_pkey_integer +0.3%.

• make_report.py takes the words of a report from its json (story), so a report is no longer written for one release.

v7.25.19 (2026-09-30)¶

The end of the lost webstats report of wattyzer, and what it turned up: the report’s IP addresses as [a.b.c.d] (OVH read one as a phone number and dropped the mail), secrets masked where attrs are shown, the persistent-attrs file 0600, and the SMTP refusal text in the log. A kernel change, so the suite ran on both machines (215/215 each); deployed as emailsender and webstats on every node -- the other yunos take the masking at their next build.

Kernel: secrets are not shown, and not left world-readable¶

• SDF_SECRET, a new attr flag: the attr is read, written and persisted as before, and SHOWN as ******** by view-attrs, write-attr (its answer echoed the value written), list-persistent-attrs, view-gobj and the start-up trace of the yuno’s attrs -- through the new gobj_mask_secret_attrs(). Marked: the passwords of the emailsender and its SMTP session, client_secret (auth_bff), sign_secret (assets), kc_admin_client_secret (keycloak), the MQTT password, and the user passwords and tokens of c_task_authenticate, c_ievent_cli, c_tcp, mqtt2 and the CLI tools. view-attrs showed the relay’s password in clear to whoever asked.

• The persistent-attrs file is written 0600 (dbsimple.c), and fchmod’ed so the files written before are closed at their next save: it was json_dump_file() with the process umask -- 0666 on every node -- and it holds those secrets in clear.

emailsender: a refused login says why¶

• The SMTP server’s reply TEXT is logged with its code when the login is refused. 535 alone could not tell a wrong password from what it was on 2026-09-30: 535 5.7.1 Authentication failed, OVH blocking the account.

webstats: the report’s IP addresses go out as [a.b.c.d]¶

• OVH’s outbound relay read 34.140.132.132 as a Spanish phone number (+34 and nine digits) and, in a report full of addresses marked “banned”, accepted the mail (250 queued) and delivered it to NOBODY: no bounce, not in Junk, not at gmail or outlook either. wattyzer’s report of 2026-09-29 was the first with such an address, bisected down to one row of Top clients; Google Cloud addresses start with 34, so it recurs. The mail (and preview-report) now writes every standalone IPv4 as [a.b.c.d] -- proven on the relay; the usual defang a[.]b[.]c[.]d does NOT pass. The stored record keeps the plain address.

v7.25.18 (2026-09-30)¶

emailsender and webstats only: no kernel change. Found chasing a webstats report of wattyzer that stopped arriving (OVH accepts it -- 250 queued -- and it is lost after the relay; the cause is still being narrowed down, see TODO). Each node takes it with install-binary of the two roles and the usual promotion.

emailsender: the smtp trace no longer writes the credentials¶

• C_SMTP_SESSION’s smtp trace wrote every command line, AUTH PLAIN included: the base64 of the user and password of the relay, that is the password in clear, in the yuno’s log and from there in the logcenter’s. It names the mechanism now (>>> AUTH PLAIN <credentials not traced>). Found tracing a report that did not arrive; the two lines that had been written on wattyzer were overwritten in place.

webstats: a rebuilt day with no access log keeps (and sends) the stored report¶

• The guard against storing an empty rebuild over a good day measured the lines KEPT from every source; the fail2ban and error logs of a day outlive its access log, so rebuilding such a day (report-day ... send=1 after the rotation) passed the guard and stored -- and mailed -- NO DATA over a day of 4632 requests. It measures what the report saw now (requests + errors, the NO DATA of the subject), and a rebuild asked to send mails the STORED report. load_report answers the newest record WITH data when a later one is empty (the store is append-only: the good day was never lost), which also mends the days already written that way.

webstats: send-yesterday¶

• Builds the report of yesterday and mails it, whatever send_email says, with nothing to type -- report-day wants the date and send=1. analyze-now says in its help that it mails only when send_email is on.

v7.25.17 (2026-09-30)¶

Kernel: C_TCP_S and C_UDP_S answer help¶

• They were the only gclasses with commands (reload-certs, view-cert) and no help: command-agent service=agent_secure_port command=help answered “command not available”, and the commands could only be found in the code. Every gclass with a command table in the SDK and in the projects now has one (the two command-parser test fixtures excepted). Deployed with the agents and the control center; every other yuno gets it at its next build.

• view-cert says in its description that it answers the listening url too. The transport page documented a help that did not exist and a view-services that does not; it lists the three real commands now.

JS: gui_agent 0.29.5¶

• “For TreeDB” gives each agent its own domain. The export built an agent’s url from the node’s name (wss://artgins:1993), because the scan read the certificate from view-config, where the agent’s is a global override it does not see. It asks the agent’s secure gate view-cert instead: the loaded certificate’s CN (wss://agent.artgins.com:1993) and the gate’s port. A CN that is not a hostname -- the package’s own self-signed yuneta_agent.yuneta.io -- falls back to view-config and the node’s name, as before.

v7.25.16 (2026-09-30)¶

A lite release (control center and agent only): the two points the review of 7.25.15 left in TODO.

Control center: two editors of one scenario¶

• save-scenario takes the revision the scenario was read at and refuses the save when it was saved (or deleted) since, naming who -- instead of the last writer silently winning. The revision is the record’s g_rowid, which scenarios and save-scenario now answer in __md_treedb__ (updated_at counts seconds: two saves in one second look the same). Without revision, or 0, nothing is checked: a new scenario, or an overwrite on purpose.

Agent: a yuno that runs but is not connected is answered for¶

• command-yuno, stats-yuno and authzs-yuno sent nothing, and answered nothing, for a matched yuno whose row has no channel (starting, or going): the requester waited for ever, a control center running a scenario for its step’s whole deadline, with every other run held behind it. Now the command is answered at once with an error when it reached none of the yunos, and logged when it reached only some.

JS: gui_agent 0.29.4¶

• The live view keeps the revision of the scenario it shows (from the list and from each save) and sends it with a save of the same scenario; a refusal says somebody saved it after it was opened (scenario changed since read). A save under another name, confirmed first, is an overwrite and sends none.

v7.25.15 (2026-09-30)¶

A lite release (control center and agent only, rule of 2026-09-29): only those two binaries change, and only they are deployed. It closes what a review of the scenarios and their live view found, after running the yunovatios-stress scenario end to end from the console.

Control center: a web client is its connection; runs end when their agent goes¶

• A stats reading for a closed tab could reach another user. The relay of EV_YUNO_STATS found the web client by the NAME of its channel in __top_side__, and that name is taken by the next client once the first closes -- while the agent’s watch goes on pushing until it expires (watch_ttl, 60 s). Each connection now gets a number when it opens, command-agent stamps it on what it forwards (cc_connection, kept by the agent with the watch), and a reading -- like the answer of a run-scenario -- is delivered only while the channel holds the same connection.

• Use after free in that relay: the name of the channel was read from the popped stack frame after it was freed, in the warning for a gone client.

• A run whose node’s agent disconnects ends at once, not at the step’s deadline (run_step_timeout, 30 s, during which every other run waited).

• Pausing the control center in the middle of a run answers its requester: the run was ended after the web side had been stopped, so the answer was always dropped.

• save-scenario refuses what command-yuno would misread. A step parameter named like one of command-yuno’s (id, service, command) or like a column of the agent’s yunos topic (date, yuno_name, ...) became the filter that selects the yuno -- another yuno, or “Yuno not found”. A service and a yuno id are letters, digits and _ . ^ -; a scenario id is letters, digits and _ . @ -, not starting with a dot (timeranger2 refuses it as a key), 200 at most (a run id that would not fit is refused, not truncated).

• Documented: the steps run on the control center’s session, so write-scenarios together with run-scenarios is as much as command-agent.

Agent: watch-yuno-stats tells two tabs apart, and takes what it can¶

• The requester of a watch is told by its first hop AND the channel it came in by at the control center (input_channel): two tabs of one browser were one requester, the second replacing the first watch at each renewal, and a hidden tab stopping the other’s.

• One yuno can be watched through several services (ids=5120,5120:db); the last one named used to replace the others.

• An id that is not a yuno of the agent no longer refuses the whole watch: it is watched, its state says missing, and the answer names it (data.missing).

JS: gui_agent 0.29.3¶

• The live view stops the agents’ watches on Disconnect, when it is stopped and when another scenario is shown (behind the control center a watch pushed on until its ttl); readings asked for, or pushed by the watch of, the scenario shown before are dropped (monitor_gen) instead of landing on a card with the same key.

• One control at a time, with its number on every request; a restart goes in phases (stop, resets, start), each waiting for all the answers of the one before; a control not answered in time or cut by a drop says so.

• A watch the control center could not dispatch is asked again at the next renewal instead of turning that node to polling for good.

• Restart only when the scenario has a stop; the editor refuses the same step parameters as the control center; units of the selectors translated; the list opens a row while it re-reads and re-reads after a change that landed during a read; the direct link tears itself down outside the publish that refused it and lets go of the login’s refreshes when stopped.

JS: tabulator-tables ^6.6.0 in every SPA; gui_agent 0.29.2, gui_treedb 0.17.73¶

• 6.6.0 is additive for these apps (an opt-in range fill handle, an initialValue for editors, a Bootstrap 5 border fix). Every SPA of the ecosystem raised its floor, was rebuilt, deployed and checked live; the gobj-ui lockfile and its test-app follow (the library’s ^6.5.3 range already takes it, so no publish).

JS: gui_agent 0.29.1¶

• The scenarios list reads itself again whenever its tab is shown, so the runs it counts are current (they only moved on a save or a delete).

v7.25.14 (2026-09-29)¶

A lite release (controlcenter only, rule of 2026-09-29): only the control center’s binary changes, and only it is deployed.

Control center: the scenarios, in its treedb; its dead topics gone¶

• treedb_controlcenter keeps the scenarios (schema_version 3, treedb_schema_controlcenter.c): topic scenarios -- a set of yunos on one or several nodes, how the messages flow between them (links) and the commands of each action (start, pause, resume, stop, report), a document saved whole -- and topic scenario_runs, each run linked to its scenario. New commands scenarios, save-scenario (validated: the same rules as the console’s editor), delete-scenario (with its runs), run-scenario scenario_id= action= and scenario-runs, with the permissions read-scenarios, write-scenarios and run-scenarios, checked by the commands always. The parameter is scenario_id, never id: through an agent’s command-yuno the id of the kw is the yuno’s.

• run-scenario runs an action on the nodes, one step after another, each as command-yuno id=<yuno> [service=] command=<command> to its node’s agent, as the user who asked. A step that fails or does not answer in run_step_timeout (30000 ms) ends the run; the run is written to scenario_runs (every step with its answer, and for a report what each step answered) and the command answers when it is over. One run at a time.

• Removed, unused since the webix GUI: the topics systems, nodes, services (declared inventory, viewer launcher) and users (a copy of each user at login, read by nobody: the users are the authz store’s), the lists / viewer_engines draft, ac_treedb_node_* (they acted only on a treedb_purezadb of another project), the attrs enabled_new_users and enabled_new_devices, and the authz entries list-groups, list-tracks, realtime-track. On a.com the three inventory topics were empty.

• A login is no longer refused while the control center boots. ac_user_login() answered EV_AUTHZ_USER_LOGIN -- a veto point -- with -1 until its treedb opened, only because it could not copy the user yet; that refusal went with the users topic, and so did the “Treedb Controlcenter not ready” warnings a restart logged while the agents reconnected (YUNO_AUTH.md §4.9).

• C_AUTHZ: EV_AUTHZ_USER_LOGIN/LOGOUT/NEW are EVF_NO_WARN_SUBS. Their subscribers are optional (the agent, the mqtt broker); a yuno that has none logged “Publish event WITHOUT subscribers” on every login -- the control center did, from the moment it stopped subscribing (seen deploying this release on a.com: 29 in the first minute). Reaches each yuno at its next rebuild.

JS: gui_agent 0.29.0, the Scenarios workspace, in place of Monitor and Statistics¶

• The console’s side of the control center’s scenarios: Scenarios (the list the control center keeps), Yunos (ticking yunos watches them as cards of every counter -- what the Statistics workspace was) and Live (the graph and charts, or the cards). Actions replace the old test block; a saved scenario is run BY the control center (run-scenario) and its runs are listed; any other one runs from the console. Against a control center older than 7.25.14 it keeps the scenario in the browser, as before.

• The Statistics workspace is gone (it is a scenario of cards now), and the rail has five workspaces again.

JS: gui_agent 0.28.0, the Users workspace¶

• The users each yuno lets in, and their roles, from the console. Every yuno that authenticates keeps its own store (each node’s agent, each control center: 1996 and 1997 are two), so Users is a per-yuno workspace: the nodes->yunos tree marks the yunos that keep users (a C_AUTHZ with its treedb_authzs) and whether each is the master or a read-only replica, and a tab lists the users of one store and creates, enables, disables, deletes and gives or takes roles. Every write is a C_AUTHZ command over the agent; a role is a link-nodes / unlink-nodes on treedb_authzs, because update-user role= autolinks and REPLACES every role the user holds by that one.

• It makes the open per-command authz gate visible: create-user & co. run for any operator the control center lets run command-agent, even with no role in that yuno’s store, while link-nodes checks update on its own (TODO.md, “per-command authz gate”).

• First step of the control-center treedb plan (TODO.md, “Controlcenter: scenarios in its treedb”).

v7.25.13 (2026-09-29)¶

Agent: watch-yuno-stats, the stats of yunos pushed to whoever watches¶

• New agent command watch-yuno-stats ids=<id>[:<service>],... period=<ms> (stop=1 ends it): the agent keeps the requester’s route -- the way open-console does -- and SENDS it EV_YUNO_STATS every period, per yuno a state (running, playing, disabled), a cpu (its __yuno__ stats) and an app (its service’s stats). The readings are taken on loopback once per yuno and service however many watch it, at the shortest period asked; watch_min_period (1000 ms) and max_watches (30) bound it. The watch ends with its requester’s connection. A subscription could not do this: they go from a client to a server only, and the agent is the server of its yunos.

• New kernel event EV_YUNO_STATS (g_ev_kernel).

• One watch per requester = its connection plus the client at the far end of the route (every web client of a control center shares its connection), and it expires after watch_ttl (60000 ms) unless asked again: behind a control center the agent never sees a browser leave. The answer carries the ttl.

• The control center relays EV_YUNO_STATS to the web client, like the PTY mirror. command-agent now adds __relays__: ["EV_YUNO_STATS"] to the kw it forwards (after removing one the client may have sent), and the agent refuses a watch through a control center without it: a control center that gets an event it does not know drops the agent’s connection. A reading for a web client that is gone is counted and said once a minute.

• gui_agent’s Monitor (0.26.0-0.27.0) uses it directly and through the control center, per node, and polls a node whose agent or control center refuses the watch.

• ac_timeout_periodic of C_AGENT now tells its periodic timers apart by src (cert-sync and the watch), and logs a tick of an unknown one.

JS: gui_agent 0.23.0 - 0.27.0, the Monitor workspace¶

• A test, live, from its agent. gui_agent gains a fifth workspace, Monitor: a left-to-right graph of the yunos of one scenario (the agent url, the yunos, the links the messages follow) with cpu %, msg/s in and out, queue and state per yuno, and two uPlot charts over a 5-60 minute window. First written for yunovatios’ stress tests (sim_controllers -> gate_central -> db_tracks_ce), and it matches what ycommand measures on them.

• It is the first transport of the console that does not go through the control center: it talks to the agent’s wss://<node>:1993 with the access_token it gets from the BFF’s /auth/token, so that plane’s BFF needs expose_access_token (YUNO_AUTH.md §2.2). The agent must serve a certificate a browser trusts; the self-signed yuneta_agent.yuneta.io does not.

• A test gets controls (0.24.0): a test block in the scenario declares Start / Pause / Resume / Stop as lists of commands of the generator (sent as command-yuno), and Restart is stop + stats-yuno stats=__reset__ to every yuno + start. Confirmed in a dialog that lists the commands; a production scenario (no test) shows none. A service that keeps its counters in private fields behind mt_reading does not honour __reset__ unless its mt_stats does it (the yunovatios yunos do not yet).

• Through the control center, several nodes (0.25.0): a scenario that says node instead of agent_url sends every command as command-agent agent_id=<node> on the console’s own link — no token leaves the BFF and the nodes need no browser-trusted certificate. Propose links reads the yunos’ view-config and proposes the links from what they listen on and connect to.

• The readings are polled (the Statistics exception, extended to this view) until the agent can publish stats to a subscriber (design in TODO.md, “Stats pushed to a subscriber”); TODO.md “Stats: three things a live monitor cannot trust” lists what a monitor finds in the SDK stats today.

tr2check: check a topic filled by a load test¶

• New tool utils/c/tr2check (installed in /yuneta/bin, shipped in the .deb/.rpm). In one pass per key it gives what an acceptance test asks in SQL: record count, duplicates, gaps and missing records (--expected), out-of-range sequences, checksum mismatches (--checksum-field, sha256 of the record as compact json with sorted keys), the storage rate and the latency percentiles (__t__ - __tm__, exact to the ms on a sf_t_ms|sf_tm_ms topic). The sequence counts per key (--seq-scope=key, the way a device numbers its frames) or for the whole topic; a record that arrives out of order is not a duplicate. One json document on stdout; exit code 0 pass, 1 a check failed, 2 the topic could not be checked. Test: timeranger2/test_tr2check.

CLI 0.20.2: sync-binaries uploads the file it compared¶

• With --yunos-dir, the table was built from the staged binary but the upload sent $$(<role>), which ycommand resolves in outputs/yunos: on a node where two projects build the same role (hidraulia’s gate_caudal), the row said REBUILD 1.9.0.0 and the upload was the other project’s 1.6.1.0. The command now carries the file’s path. The wait for a yuno to stop before a same-version update-binary goes from 15 to 60 s.

CLI 0.20.1: yunetas init keeps the ctest logs¶

• yunetas test leaves one build/<timestamp>.txt per ctest run, the history a release compares timings against, and init recreated the root build/ with rm -rf: the clean rebuild of a version bump wiped it (7.25.12 lost it on the dev machine and on wattyzer). init now carries those logs across.

v7.25.12 (2026-09-28)¶

timeranger2 (fs_watcher): a pass says where its time went¶

• The INFO that closes a pass after an inotify overflow adds slices, ms_owner, ms_watcher, ms_loop and max_loop_ms: the owner’s callbacks, the walk, and the loop’s own work between slices. On yunovatios’ central some passes took 251 and 680 s while the yuno digested a queue; measured with it, such passes are 65-78 % owner (handing over the backlog of records), 22-35 % loop and 1.1-1.7 s walk: not the watcher.

emailsender: rejected SMTP credentials stop the yuno, they are not retried¶

• When the SMTP server refuses the AUTH PLAIN, the emailsender logs one ERROR (“SMTP credentials rejected: exiting, NOT relaunched”, with the reply code, the url and the username) and exits with code 0 (LOG_OPT_EXIT_ZERO), so neither the watcher nor the agent relaunches it. It used to treat the refusal as a link drop and retry every few seconds: 768 refused logins in 54 minutes on hidraulia on 2026-09-28, the pattern that got an address banned from the whole OVH mail cluster in July. The in-flight message stays at the head of emails_queue without spending a retry. C_SMTP_SESSION reports the refusal on EV_ON_CLOSE as auth_rejected, apart from the per-message code.

CLI 0.20.0: secret overlays removed (BREAKING)¶

• yunetas list-secrets and sync-configs --secrets-dir are gone, and sync / sync-configs --node no longer read ~/.yuneta/secrets/<node>/. A credential a yuno needs goes in its config file again and is pushed as written. The "__SECRET__" placeholder was filled only by sync-configs; a node reinstall script registered the placeholder itself, the emailsender logged in with it and the mail provider banned the node. A config that still carries "__SECRET__" is now pushed with it: put the value in the file first.

emailsender: a blank password leaves the SMTP side stopped until set-email-user¶

• Batch configs leave username / password blank; the operator sets them once with set-email-user (persistent attrs, loaded over the config at every start). With either one blank the yuno now runs, queues emails and logs one ERROR, but does not start the SMTP session. It used to fail twice over: both attrs were SDF_REQUIRED, so the service refused to start and set-email-user had nothing to talk to; and a session started with no password skipped the AUTH, so the server refused every message into the dead-letter queue.

• set-email-user now applies at once: it hands the credentials to the SMTP session and starts it, and the queue is sent, with no restart.

• The cached username / password / url / from pointers are refreshed on every write (mt_writing); set-email-user ... url=... left url pointing at freed memory, which the send logs read.

Packaging: colas2.sh works again when called without arguments¶

• The /yuneta/bin/colas2.sh that the .deb and the .rpm install passed its forwarded arguments as "${FWD_ARGS[@]:-}", which, with none, is ONE empty argument, not zero. list_queue_msgs2 takes exactly one path, so every queue answered “Usage: list_queue_msgs2 [OPTION...] PATH”: the script failed in its plainest use, on every node, since the .deb version of 2025-09-04. It now expands ${FWD_ARGS[@]+"${FWD_ARGS[@]}"}, which is nothing when there is nothing and safe under set -u.

v7.25.11 (2026-09-27)¶

Found by the third gate-outage test of yunovatios’ central: three “Event NOT DEFINED in state” that a connection going down produced, all in the window between a transport deciding to close and the layers above learning it; and a pass after an inotify overflow whose own cost grew with the tree. Rebuild every yuno (TCP and websocket clients, rt_disk followers) and the agent.

root-linux: data that arrives or leaves while a connection closes¶

• C_WEBSOCKET, receiving while closing: ws_close() moves the gobj to ST_DISCONNECTED and sends its Close frame; a client keeps the connection until the server drops it or timeout_close runs out, as RFC 6455 asks, and a server’s pending read still completes. What arrives then (the rest of a frame given up on, the peer’s Close) came as EV_RX_DATA, which the state did not declare. It is now discarded, nothing published (debug trace level). Seen on a sim of controllers too busy to read a frame within timeout_payload. Test: tests/c/c_websocket (new).

• C_TCP, sending while closing: a drop or a disconnection waits in ST_WAIT_STOPPED for its last io_uring operation before it publishes EV_DISCONNECTED, and until then the layers above send. That EV_TX_DATA was undeclared there -- ten thousand ERRORs in an hour on a sim of 300 controllers whose central went away. It now goes where the pending queue of a dead connection goes (away; connections trace level). Test: c_tcp/test7.

• Documented in api/gclass/protocol.md (C_WEBSOCKET: the states corrected, timeout_close, a Closing section) and api/gclass/transport.md.

timeranger2 (fs_watcher): the pass after an overflow, at a cost that does not grow with the tree¶

• 7.25.10’s sliced pass rebuilt, in EVERY slice of 20 ms, the index of the watched paths by path (the watch table is indexed by wd): 50000 entries per slice. The watcher’s own cost per directory grew with the tree -- 254 us at 69632 directories -- and on yunovatios’ central a pass over 50501 key directories took 7 minutes, and the next one more than 20. The index is now built once per pass (and grows with the watches the pass adds): 73 us per directory, a pass of 16 s instead of 29 in the test.

• test_fs_watcher_overflow now measures that cost (the pass less the owner’s time) and fails above 200 us per directory.

yuno_agent, controlcenter: an answer for a client that left¶

• A command or stats answer, or a counted one (kill-yuno, run-yuno, ...), for a client that left before it (a ycommand that timed out) was sent to its channel, CLOSED by then: “Event NOT DEFINED in state” with a stack. The agent and the controlcenter now check that the requester is still listening (its channel opened, or a link in session) and drop the answer with an INFO “requester gone before its answer, answer dropped”.

v7.25.10 (2026-09-27)¶

The recovery from an inotify overflow (7.25.9) now keeps the yuno answering: the pass over the watched tree runs in slices of 20 ms per loop turn. Found by the second gate-outage test of yunovatios’ central, where one pass held a db_history_ce deaf for four minutes. Every yuno that reads a timeranger2 topic of another yuno must be rebuilt against this SDK.

timeranger2 (fs_watcher): the pass after an overflow gives the loop back¶

• 7.25.9 recovered from an inotify overflow in one piece: the owner rescanned the whole tree inside the single FS_OVERFLOW_TYPE call. A timeranger2 follower of 50000 keys on the busy disk of yunovatios’ central took 56 s, then 243 s, and the yuno answered nothing meanwhile -- its agent, its commands, its timers.

• Now the watcher runs the pass itself, a slice of 20 ms per loop turn: every directory of the tree goes to the owner as the new FS_RESCAN_DIR_TYPE, and a directory born in the overflow is watched first (one walk does both: the separate walk that re-set the watches is gone). FS_OVERFLOW_TYPE stays, for what is global and cheap. Another overflow during a pass adds one more whole pass after it. INFO “watched tree rescanned after lost inotify events”.

• A follower’s rt_disk feed finds the keys deleted while the events were lost by reading keys/ once (it was a stat() per key), and reads one key directory per FS_RESCAN_DIR_TYPE. The master and C_FS ignore the directories; the fs_watcher CLI prints them.

• Test: timeranger2/test_fs_watcher_overflow (a real overflow, an owner slow on purpose and a timer probing the loop: every directory told, a pass of ~30 s, the loop deaf at most 50 ms). test_rt_disk_overflow still covers the follower. Documented in api/timeranger2/fs_watcher.md.

v7.25.9 (2026-09-27)¶

An inotify queue overflow no longer aborts the yuno: the watcher recovers in place and its owner rebuilds its view from the filesystem, where what the lost events said still is. Found by yunovatios’ stress test of its central, where a db_history_ce following a busy db_tracks_ce lived in a crash loop under a burst. Every yuno that reads a timeranger2 topic of another yuno (an rt_disk feed) must be rebuilt against this SDK.

timeranger2 (fs_watcher): an inotify overflow no longer aborts the yuno¶

• An IN_Q_OVERFLOW of a watcher aborted the yuno to be relaunched and reload clean. Under a sustained burst the reload met the next overflow: in yunovatios’ stress test of its central, a db_history_ce following a db_tracks_ce at ~3000 records/s over ~60000 keys aborted five times in two hours, and each relaunch spent 2-3 minutes catching up before falling again.

• Now the watcher recovers in place: a WARNING, a watch set on every directory of a recursive tree that was not watched, and the owner called once with the new FS_OVERFLOW_TYPE to rebuild its view from the filesystem, where what the lost events said still is.

• A follower’s rt_disk feed scans every key directory of its disks/<rt_id>/ (a link still there is a record not handed over yet) and compares its cache with the topic’s keys/ (a key gone is heard deleted, its key_deleted callback fires). Idempotent: nothing is handed over twice. INFO “rt_disk feed rescanned after lost inotify events”.

• The master’s watch of disks/ closes the feeds whose directory went and opens one for each directory without it (find_rt_disk() skips an rt_id already fed).

• C_FS publishes EV_FS_CHANGED for the root; utils/c/fs_watcher prints it, and no longer reads the event types as bits (a “file created” printed as “directory created” and “directory deleted” too).

• Test: timeranger2/test_rt_disk_overflow (a real overflow: 69632 new keys with the loop stopped, one IN_CREATE each, and a key deleted while the queue is full; every record once, the delete heard once, a key born in the overflow watched after; with the old code it aborts). Documented in api/timeranger2/fs_watcher.md.

v7.25.8 (2026-09-26)¶

A TLS fix in C_TCP: under a burst, a connection could have two writes in flight, and a short one then sent its rest out of order -- the peer answered “bad record mac” and dropped the link. Found by yunovatios’ stress test of its central, where the drain after a gate outage barely converged because of it. Every yuno that speaks TLS must be rebuilt against this SDK (the gclass is linked into each binary).

TCP (C_TCP): TLS “bad record mac” under a burst -- one write in flight¶

• A TLS connection could have two writes in flight, and a short one then sent its rest after the other: the byte stream went out of order and the peer failed the record MAC (“SSL_read() FAILED”, error:0A000119, “decryption failed or bad record mac”), dropping the link. ytls hands its encrypted output over from several places (the message being written, the handshake, the records after it) and ac_send_encrypted_data started a write for each at once; and the completion of any write took the next message while another was still in flight. It shows under a burst on a full socket -- clients resending their windows when a gate comes back -- and how often depends on the kernel: yunovatios’ stress test of its central (Rocky 9, kernel 5.14) dropped links 13606 times in 25 minutes, and the drain after a 4-minute outage barely converged.

• Now a connection has ONE write in flight, TLS included: encrypted output waits in a queue while a write is in flight, it goes before the next clear message, and the queue is discarded with the TLS session it belongs to. The plain path already kept the rule.

• New stat max_tx_in_progress of C_TCP: the most writes ever in flight at once, 1 by the rule.

• Test: c_tcps/test5 (10 bursts of 400 x 64 KB over TLS to an echo server, every echo checked in order, and max_tx_in_progress == 1 asserted: with the old code it is 2 on every run, while the echoes alone came back intact in most runs). Documented in api/gclass/transport.md (One write in flight).

• ac_send_encrypted_data answers 0 when its write cannot start (logged, the connection dropped): the mbedTLS backend frees the gbuffer again on a negative answer, which the kw had already released.

v7.25.7 (2026-09-26)¶

A leak fix and nothing else in C: every return from inside a SWITCHS case lost a compiled regex, and every gate with an output queue returned from one per message. Found by yunovatios’ stress test of its central. The JS submodules move to maplibre-gl 6.11.2 and vite 8.3.1. Every yuno must be rebuilt against this SDK to lose the leak.

Helpers: a return inside a SWITCHS case leaked a compiled regex¶

• SWITCHS compiled a regex (".*") on entry and only SWITCHS_END freed it, so every return (or goto) out of a CASES body lost glibc’s compiled automaton, a few KB per switch, allocated by regcomp(3) OUTSIDE gbmem: invisible to the gbmem audit and to cur_system_memory. 29 of the 63 SWITCHS of the tree return from a case, several once per message: C_MQIOGATE’s ac_send_message (every gate with an output queue lost ~1.1 KB per message; a gate_central of yunovatios’ stress test reached 1 GB in 25 minutes), c_prot_modbus_m, tr_treedb, tr_msg2db, yev_loop and the frame decoders of the projects. Found by a gdb breakpoint on malloc (gbmem allocates with calloc, so malloc catches only what bypasses it).

• Now SWITCHS allocates nothing and CASES_RE matches through the new str_match_regex(), which compiles, matches and frees on the spot: leaving a switch from anywhere is safe, and no caller changed. The usage is the same.

• Every yuno that uses SWITCHS must be rebuilt to lose the leak: the macros are expanded where they are used, so an old binary keeps it.

• Test: helpers/test_switchs (100000 x 3 returns from inside cases: +1.06 GB of libc heap with the old macro, +1 KB with the new one; matching unchanged). Documented in api/helpers/string_helper.md (str_match_regex() and the switch).

JS: gobj-ui 7.25.23, gui_agent 0.22.99, gui_treedb 0.17.72¶

• maplibre-gl 6.11.2 and vite 8.3.1. gobj-ui 7.25.23 raises its peer floor to maplibre-gl ^6.11.2 and builds with vite ^8.3.1; no API moved. gobj-js builds with vite ^8.3.1 (7.25.8 is not republished). gui_agent and gui_treedb take gobj-ui ^7.25.23 and vite ^8.3.1, and are deployed. maplibre 6.11.2 changes the glyph protocol between its worker and the page: a host that emits the worker keeps the version in the file name (maplibre-gl-worker-6.11.2.js), as the gobj-ui test-app does, or a browser that cached an older worker loses the map labels.

v7.25.6 (2026-09-25)¶

What changed after 7.25.5: the tests that failed on the nodes, one of them over a real defect of the static resolver, and the open-files limit of the agents. No change in timeranger2, treedb or the transports.

Event loop (yev_loop)¶

• The static resolver (CONFIG_FULLY_STATIC) sent a numeric address of the other family to DNS: getaddrinfo("::1") asked for AF_INET (a src_url of [::1] bound for the IPv4 address of a destination) fell through to an A query, and a slow nameserver stalled the event loop (3.1 s on wattyzer, WARNING “getaddrinfo() BLOCKED the event loop”). It answers EAI_ADDRFAMILY at once now, as glibc does, and AI_NUMERICHOST with a name answers EAI_NONAME with no lookup. Test: test_static_resolv_numeric.

Packages (deb, rpm)¶

• The init script started the agents with 200000 open files, while pam_limits gives a login fs.nr_open (4000000): it raises them to fs.nr_open now, and logs with logger when it cannot. /etc/profile.d/yuneta.sh asked for ulimit -n unlimited, which Linux refuses for open files (a no-op); it raises the soft limit to the hard one now, which also lifts the 1024 that systemd gives a desktop terminal. Takes effect at the next boot or login.

Tests¶

• New raise_open_files_limit() (testing.h): raises the soft limit of open files to the hard one. test_iterator_index, test_c_treedb_literal_wins and perf_c_treedb open more than 1024 files and failed with “TOO MANY OPEN FILES” in a terminal that systemd started with its soft limit of 1024.

• test_torn_tail_check_fails 5a/5c passed only with CONFIG_DEBUG_TRACK_MEMORY: the lexer’s 64 KB buffer fits a 64 KB block when no tracking header is added. The block of case 5 is 48 KB.

• test_unlisted_relist_once 4 failed on kernels before 6.13, where a ctime moves in ticks of the coarse clock (4 ms): the chmod fell in the tick of the flag. It repeats the chmod until the ctime moves.

• test_c_treedb_literal_wins: a child that cannot take its own io_uring ring prints why before it exits.

v7.25.5 (2026-09-25)¶

What changed after 7.25.4. Each behaviour change has a test that fails on the code before it, except those listed under “No red test” in TODO.md.

Upgrade steps (operators, read first)¶

• Nodes that build from source: rebuild the external libraries first. linux-ext-libs is 1.22 (a patched jansson): run cd kernel/c/linux-ext-libs && ./extrae.sh && ./configure-libs.sh, then yunetas clean && yunetas build (it refuses a stale outputs_ext until then).

• Before upgrading a node, look for md2 files that are not whole rows: find /yuneta/store /yuneta/realms -name '*.md2' -printf '%s %p\n' | awk '$1 % 32'. A file that 7.25.4 wrote after a torn row is not cut by this release: its key fails every load (CRITICAL “...not cut, repair it by hand”) until it is repaired. treedb.md, “A topic that did not load whole”, gives the repair: a script that is linear (86 400 rows in 0.13 s) and runs in a set -e subshell. It names its backup ~/<topic>.<key>.<file>.orig and refuses to overwrite one, writes through $f.tmp + mv (a failure leaves the .md2 unchanged), and writes nothing when more than one boundary passes. A scan of ~21 500 md2 files on four stores (local, wattyzer, both yunovatios) found none. See deploying-yunos.md.

• Before upgrading, run save-schema for any draft you want to keep. An unsaved draft that added a topic or column is taken as left by 7.25.4; a topic deleted as an unsaved draft is restored by the first open when the file in use is the literal. See deploying-yunos.md.

• The agent removes audit files older than 7 days at its first start. To keep more, set "agent.audit_keep_days": <days> in the global section of /yuneta/agent/yuneta_agent.json BEFORE you start the new agent (0 keeps all). See DEBUGGING.md 5.5.

• Migrate the timeranger2 topics once, after upgrading. Until a topic created by 7.25.4 or earlier is migrated, no file’s tm range is trusted in it, and a tm query (from_tm / to_tm) reads every md2 row of the key. On the master, for each tranger service of each yuno (find them with command-yuno id=<id> service=__yuno__ command=services): command-yuno id=<id> service=<tranger> command=mark-tm-order all=1. The agent is not a managed yuno (command-yuno does not reach it); its own trangers are three: command-agent service=tranger_treedb_yuneta_agent command=mark-tm-order all=1, command-agent service=tranger_system_schema command=mark-tm-order all=1 and command-agent service=tranger_authz command=mark-tm-order all=1 (its C_AUTHZ is the master of treedb_authzs, whose users_accesses has 'tkey': 'tm'). The migration reads every md2 file once, is linear in the number of files, and blocks the yuno while it runs (1 key x 30 files x 20 000 rows: ~19 ms). The price until then is under “Performance”. See deploying-yunos.md.

• If the main agent does not come back after the upgrade, look in its log for “treedb ‘treedb_yuneta_agent’ did not open, its schema was refused” (syslog has “Cannot start agent treedb: ...”): when its treedb’s schema is refused, the agent now exits 0 and is not relaunched. Reach the node through yuneta_agent22.

• The first open of each treedb after the upgrade reads what 7.25.4 left in __system__. It writes saved_schemas/<treedb>.upgrade.json under the __system__ tranger; do not delete it. Expect once per treedb, where a first projection of 7.23.0-7.25.4 died after its stamp: WARNING “Restored from the schema from C: ...” when the file in use IS the literal, or, when that open installs a newer literal, INFO “What system misses of the schema file in use is no deletion of the operator’s: ...” (the literal is then projected). When that open’s literal is newer, also WARNING “Removed from system what an older release left there: ...” and withdrawn_at_open kind left_by_older_release. None of them is operator work.

• Do not roll a node back to 7.25.4 or earlier for topics created or migrated by this release without running mark-tm-order again after coming forward: an older binary appends out-of-order tm rows without writing the marker, and a tm scan can then hide rows.

• denied_ips refuses at accept now, on every TCP and UDP listener of the yuno. In 7.25.4 an ip in a yuno’s denied_ips was refused only at the login of a gate that authenticates. After the upgrade C_TCP_S closes its connection at accept and C_UDP_S drops its datagrams, also on a gate that does not authenticate (see “Security”). Before upgrading, review each list: command-yuno id=<id> service=__yuno__ command=list-denied-ips (the agent: command-agent service=__yuno__ command=list-denied-ips). To ban an ip: add-denied-ip ip=203.0.113.7 denied=1. denied is required: without it the command answers -1, “<role^name>: Denied, TRUE or FALSE?”, and denied=0 writes false, which denies nothing. A C_UDP_S with only_allowed_ips now drops every peer that allowed_ips does not name (7.25.4 never read the attribute): check list-allowed-ips on those yunos too. Loopback is exempt from both lists. C_UDP_S says a refused peer at its first datagram of each cause and then at most once a minute; the new stat rxRefusedMsgs counts every datagram it drops (these WARNINGs are new: 7.25.4 dropped no datagram and said nothing).

• The stored ip lists are rewritten once, at the first start. A list entry is now kept in the form a peer is looked up by (see “Security”). At its first start with this release each yuno normalises its persisted allowed_ips / denied_ips and saves each list once:

  • an entry written in another form of a valid ip is renamed (WARNING “ip list entry renamed to the form a peer is looked up by”): 2001:DB8::1 -> 2001:db8::1, ::ffff:203.0.113.7 -> 203.0.113.7;

  • an entry that is not an ip is removed (WARNING “ip list entry dropped, it never matched a peer”, with the entry and the cause): a port (203.0.113.7:443), brackets ([2001:db8::1]), a host name, or a link-local address without its interface in allowed_ips. These entries never matched a peer in 7.25.4 either;

  • two entries of the same ip become one: the deny wins in denied_ips, the refusal (false) wins in allowed_ips. After the first start, look in each yuno’s log for the dropped entries and add them again in a valid form: a dropped 203.0.113.7:443 is add-denied-ip ip=203.0.113.7 denied=1. remove-denied-ip / remove-allowed-ip of an ip that is not in the list now answer -1 (7.25.4 answered success): a script that removes an ip “in case” sees a failure.

• A subscription from a peer keeps only __first_shot__ of its __config__. The C and gobj-js clients of this SDK send nothing else. A client of your own that sends other keys (__hard_subscription__, __own_event__, __rename_event_name__) has them ignored, with a WARNING in the server’s log (“SUBSCRIBING config keys a peer may not set, ignored”).

• A yuno no longer exits when a log file cannot be opened after its start. It prints one line on stdout and syslog (“_rotatory(): Cannot open ‘<path>’ file, <err>”; on a full disk the new day’s file fails at its create, “_rotatory(): Cannot create ‘<path>’ file, <err>” or “Cannot create ‘<dir>’ directory, <err>”; “_rotatory_truncate(): ...” for a truncate), goes on, and prints “_rotatory(): ‘<path>’ is open again” when the file opens again. Look for those lines in syslog: they are the only sign that a yuno is not writing its log (7.25.4 exited, see “Agent, gobj-c and tools”).

• A peer holds at most 5000 subscriptions on a channel of a gate. New C_IEVENT_SRV attributes max_subscriptions (default 5000, 0 no limit) and max_subscription_size (default 16384 bytes of compact json, for the __filter__ and the __global__ of a peer’s subscription). A subscription beyond them is refused, with a WARNING logged once (“SUBSCRIBING refused, the peer holds max_subscriptions”). A gate whose peers subscribe per device must raise the cap before the upgrade: the SPAs of hidraulia subscribe twice per device. Set it in the kw of the C_IEVENT_SRV of the gate’s channel tree, for example {"name": "input-(^^__range__^^)", "gclass": "C_IEVENT_SRV", "kw": {"max_subscriptions": 20000}} (see ievent.md, “What a peer may hold”).

• A peer’s __global__ keys that start with _ are dropped, with a WARNING (“SUBSCRIBING keys a peer may not set, ignored”, with keys, at most one each 10 s), as are a gbuffer key and the peer’s __local__: of a peer’s subscription C_IEVENT_SRV keeps only __filter__, the allowed __config__ keys and the __global__ keys of the peer’s own (see “Security”). The C and gobj-js clients of this SDK send no such key.

• The logcenter’s C_GSS_UDP_S has caps now, and the logcenter runs on their defaults: max_channels 1024 (peers, a source ip:port each, held at once; a new peer beyond it is dropped), max_pending_bytes 8388608 (8 MB of unfinished frames of all peers together; beyond it a datagram is dropped with its peer’s unfinished frame) and max_frame_size 1048576 (1 MB; a bigger frame is delivered cut). A logcenter that hears more than 1024 yunos at once sets max_channels in its config.

• A client of your own must send its routing on every frame of a session. C_IEVENT_SRV closes the channel when a session frame has no routing: no __md_iev__ ievent stack, a top record whose src_* fields are not strings, or a dst_* or __msg_type__ that is not a string. It logs one WARNING (“Frame without its routing (md_iev ievent stack), channel closed”, MSGSET_PROTOCOL, the kw capped to 256 bytes), at most one each 10 s. The C and gobj-js C_IEVENT_CLI of this SDK send the routing on every frame. In 7.25.4 such a frame logged an ERROR with a stack and the whole kw, and was processed (see “Security”).

• A C_UDP_S with a udps:// url stops its yuno at the start. There is no DTLS: the start is refused with an ERROR (“A secure url (udps://) is not supported by C_UDP_S: there is no DTLS”), and with exitOnError (the default) the yuno exits with 0, so it is not relaunched. In 7.25.4 the server listened with no TLS session, and the first datagram crashed the yuno. Before upgrading, look for such urls and write udp:// instead: grep -rln 'udps://' /yuneta/realms --include='*.json'.

• An MQTT peer that acks a message with the wrong packet is disconnected. A PUBACK for a QoS 2 message, a PUBCOMP for a QoS 1 message or before the PUBREC (and, in the client, a PUBREL of the wrong QoS) is a protocol error: a WARNING (“QoS mismatch”, MSGSET_MQTT, with client_id and peername), the connection is closed (an MQTT 5 peer first gets DISCONNECT 0x82, protocol error), and the message stays in flight for the next session, as mosquitto does. In 7.25.4 it was an ERROR, and the message was removed as delivered. An ack of a packet id that is not in flight is a WARNING now (“Message not found in trq_out_msgs”; it was an ERROR). A device that sends such acks is disconnected at each one: look for “QoS mismatch” in the broker’s log after the upgrade, and fix the device.

• A C_TCP_S says a refused connection once a minute per cause. The first connection that the ip lists refuse is logged (INFO “TCP_S: Ip denied” / “TCP_S: Ip not allowed”), then at most one line each 60 s per cause, with refused (the connections of that cause refused since the last line, that one included), refusedConnxs and next_log_in_ms. The new stat refusedConnxs counts every refusal. An alert that counts those lines counts causes now, not connections: read refused, or the stat (command-yuno id=<id> service=__yuno__ command=view-attrs gobj=<full name of the C_TCP_S>). In 7.25.4 each refusal wrote its line.

• A C_TRANGER handle opened through the agent is its user’s. A handle (open-rt, open-iterator, open-list) is owned by the channel it was opened by and the user it was opened as. Through the agent (command-yuno) every operator reaches the yuno by one link, so the user decides: another user, or a relayed command that carries no user, gets -403 on close-rt, close-iterator, close-list, get-page and get-list-data (“<role^name>: <kind> ‘<id>’ is not yours: another session opened it”). Two sessions of the same user through the agent are one owner. A handle opened through the agent is not closed when the operator’s session ends: close it with close-rt / close-iterator / close-list as the same user.

• Use the yunetas CLI 0.19.4 (pipx upgrade yunetas). find-new-yunos now marks a row already registered at the new release, and yunetas upgrade-yunos 0.19.4 counts those rows apart (N created, M already registered); 0.19.3 works with this agent but counts them as created.

Security¶

• A remote peer’s subscription changed the event of every later subscriber (HIGH; 7.25.4 too). gobj_publish_event() gave every subscriber the same kw, and applied each subscription’s __local__ (keys removed) and __global__ (keys added) to it. A peer that subscribed through a gate could forge or strip keys of the event for every subscriber after it and for the publisher, make a later subscription’s __filter__ drop events or pass events it should not, and have the gate’s __md_iev__ (another user’s name and channel) reach the local subscribers after the gate. A gbuffer key in a peer’s __global__ crashed the yuno: it was merged into the kw, and the gate’s serializer took the integer for a pointer -- any authenticated peer could crash the yuno remotely. Now a subscription with a non-empty __local__ or __global__ gets its own kw, a kw_twin() (a new top level; the values shared, a gbuffer increfed); the __filter__ and mt_publication_filter of every subscription see the publisher’s kw, and the other subscribers still share it, at no cost. The gate’s and the client’s mt_inject_event() work on a twin of a shared kw, and copy the __md_iev__ they write into (7.25.4 also wrote the message type into the subscription’s stored __global__). A twinned delivery costs ~0.23 us more, whatever the size of the event (see “Performance”). gobj-js 7.25.8 has the same fix (see the JS section). Test test_c_ievent_srv_peer_subs.

• C_IEVENT_SRV keeps of a peer’s subscription only what a peer may set: its __filter__, the allowed __config__ keys (__first_shot__, below) and the keys of its own in __global__. A __global__ key that starts with _ (the framework’s: __md_iev__, __md_yuno__, __service__, ...) or is gbuffer, the peer’s __local__ and any other key of the frame are dropped, with a WARNING (“SUBSCRIBING keys a peer may not set, ignored”, with keys); up to 7.25.4 each of them reached the publish. A key of the peer’s own comes back to that peer only. Test test_c_ievent_srv_peer_subs.

• A peer could hold any number of subscriptions (7.25.4 too). Each one costs a scan of the publisher’s subscriptions when it is made, and one more on every publish of its event: 20 000 subscriptions of one peer blocked the event loop for 80 s, and every later publish took 13 ms. New C_IEVENT_SRV attributes: max_subscriptions (default 5000, 0 no limit; beyond it a subscription is refused, WARNING “SUBSCRIBING refused, the peer holds max_subscriptions”, logged once until the peer is under the cap; a repeat of a subscription the peer holds takes no room) and max_subscription_size (default 16384 bytes of compact json, for the __filter__ and for the __global__; WARNING “SUBSCRIBING refused, bigger than max_subscription_size”). See “Upgrade steps”. Test test_c_ievent_srv_peer_subs.

• A peer no longer sets the size and the rate of the gate’s log lines. The WARNING of an unsubscribe that matches nothing dumps at most 256 bytes of the kw, with kw_size; it, the WARNINGs of dropped keys, the size refusal and the INFO of a withdrawal of a refused subscription are logged at most once each 10 s per kind and channel, with a suppressed count; an authz refusal (“No permission to subscribe event”) is logged once per service and event on a channel. These frames of a peer are one WARNING each 10 s per kind (the peer’s strings capped to 128 bytes, the kw to 256), where 7.25.4 logged a line per frame, an ERROR with the whole kw but for the WARNING “Service not found”: an event to a service the channel may not reach (“event ignored, dst_service not authorized for this channel”) or that does not exist (“event ignored, service not found”), a command or stats request of a service that does not exist (“Service not found”), a stats request of another service (“Not authorized to request stats of a different service”), and a (un)subscription of an event that is not public (“SUBSCRIBING event ignored, not PUBLIC or PUBLIC event”, “UNSUBSCRIBING ...”). Such a subscription also left the channel connected and deaf in 7.25.4 (the gate answered -1 and did not drop it); it is refused and the channel goes on. A role or name that is not the gate’s (“It’s not my role, channel closed”, “It’s not my name, channel closed”) is a WARNING with the routing capped (7.25.4: an ERROR with the whole routing); the channel is closed, as before. A command or stats request that names no command, or whose service is not a string, gets a negative answer (“Request without the command or stats it asks, refused”); 7.25.4 logged ERRORs with stacks and ran the command "". A peer that repeated a bad frame wrote one line (and one stack) per frame, of any size. Test test_c_ievent_srv_peer_subs (a repeated withdrawal with a 2 KB key: one line, capped).

• C_IEVENT_SRV stores of a peer’s routing only its own hop (7.25.4 too). The back-metadata of a peer’s subscription (what routes each event back to the peer) is built from the top record of the frame’s ievent stack alone: the peer’s hop, with the gate’s stamps, reversed. It is measured against max_subscription_size, and a bigger one is refused (WARNING “SUBSCRIBING refused, its routing is bigger than max_subscription_size”, at most one each 10 s). Up to 7.25.4 the frame’s whole __md_iev__ was stored, unmeasured, and sent back with every event: a peer made the gate hold, and send it again with each event, keys and hops of its choice, of any size. Test test_c_ievent_srv_peer_subs.

• C_IEVENT_SRV: a repeated subscription of a peer is kept (7.25.4 too). A frame that repeats a subscription the channel holds leaves it as it is: no second mt_subscription_added() and no second first shot. A frame that overrides a held subscription (it matches it, with another kw) replaces it. Each is one WARNING at most each 10 s (“SUBSCRIBING repeated, the one held is kept”, “SUBSCRIBING overrides one held, it is replaced”, with suppressed). Up to 7.25.4 each repeat was deleted and made again, with a WARNING that carried a stack and the whole kw. Test test_c_ievent_srv_peer_subs.

• C_IEVENT_SRV closes the channel of a session frame without its routing (7.25.4 too): no __md_iev__ ievent stack, a top record whose src_* fields are not strings, a dst_* or a __msg_type__ that is not a string. One WARNING at most each 10 s (“Frame without its routing (md_iev ievent stack), channel closed”, the kw capped). Such a frame cannot be answered nor routed back. Up to 7.25.4 it logged an ERROR with a stack and the whole kw, and was processed. The gate reads the routing with plain json calls: the kw_get_*() readers logged a wrong type with a stack and a dump of the frame. See “Upgrade steps”. Test test_c_ievent_srv_peer_subs.

• A peer’s own __username__ reached the service (7.25.4 too). The gate stamps __username__ on a command, a stats request and an event with kw_set_dict_value(), which kept a key that was already there: a peer that put its own __username__ in the kw was that user for the service, and command_parser.c’s authz check reads that key. kw_set_dict_value() now overwrites (see “Agent, gobj-c and tools”). The routing stamps (input_channel, input_service) were already overwritten. Test test_c_ievent_srv_peer_subs (a peer sends "__username__": "admin" in a command, a stats request, an event and a subscription).

• C_GSS_UDP_S (the logcenter) caps what its peers make it hold: max_channels (1024 peers), max_pending_bytes (8 MB of unfinished frames of all peers together) and max_frame_size (1 MB a frame, whose buffer now starts at 4 KB and grows): a sender of one-byte datagrams from many source ports cannot take the logcenter to its memory ceiling. See “Transports”, the per-peer label. Test c_udp_s_rx (case 4).

• C_TRANGER: a handle opened by one session is refused to another (7.25.4 too). close-rt, close-iterator, close-list, get-page and get-list-data of an id that another session opened answer -403, “<role^name>: <kind> ‘<id>’ is not yours: another session opened it”, with a WARNING (“Handle of another session, refused”, with kind, id, src and user); a peer could read the pages of another user’s iterator, or close its feed. The check runs before the liveness check, so such a request cannot reap the handle either. A handle’s owner is the channel it came by and the user it came as: through the agent (command-yuno, which reaches the yuno over its one C_IEVENT_CLI link) another user is refused (the __username__ that the agent stamps), and so is a relayed command of no user; two sessions of the same user through the agent are one owner. A local gobj is trusted. See “Upgrade steps”. Test test_c_tranger.

• jansson overflowed its buffers on a long string (v2.15.1; not fixed upstream, and the distribution’s libjansson does the same). Its lexer ignored a failed save and wrote past its buffers: a json string longer than about half of MEM_MAX_BLOCK (~8 MB with the default 16 MB) crashed the process that parsed it -- any json_load*(), json received from a peer included. linux-ext-libs 1.22 carries patches/jansson/0001-load-stop-the-lexer-when-a-save-fails.patch: the lexer stops with json_error_out_of_memory, and every allocation failure of the parser now sets that error. configure-libs.sh applies patches/<lib>/*.patch after the checkout. The ESP32 copy of jansson has the same fix.

• timeranger2: a record this process has not the memory to parse is reported (“Cannot read the record, this process has not the memory to parse its content (MEM_MAX_BLOCK)”, with its key) instead of crashing the reader; a torn md2 whose last row names such a record is flagged, not cut.

• The agent’s audit wrote secrets and keystrokes in clear text. Up to 7.25.4 each record held the whole kw of the command: check-user-pwd and set-user-pwd wrote the password, a write-attr of a secret attribute its value, and every console keystroke (write-tty) its bytes in base64, in files kept for ever under /yuneta/realms/agent/agent/audit/. A secret is now <redacted> (also inside a JSON text given as a string, under a name written with json escapes, and the credentials after Basic or Bearer ) and a keystroke is only counted (see “Agent, gobj-c and tools”, the audit record). What a peer says about itself is redacted too: user, each field of the hops of source, console_purpose and the console name of a console write (a JWT there is <redacted>), and such a field longer than 1024 bytes is written as <N bytes, not scanned, sha256:HEX>. Audit files written before the upgrade keep what they hold: remove or protect them. Test test_audit_record.

• denied_ips is asked at accept. C_TCP_S refuses a peer that the yuno’s denied_ips names before it spends a channel (INFO “TCP_S: Ip denied”, the socket closed), with or without only_allowed_ips, and the deny wins over allowed_ips; with only_allowed_ips a peer that allowed_ips does not name is refused as before (“TCP_S: Ip not allowed”). Every refusal is counted in the new stat refusedConnxs, and said on the transition: the first refusal of each cause, then at most one line a minute per cause, with refused (the refusals since the last line) and refusedConnxs (7.25.4 wrote a line per refused connection, so a denied host that reconnects in a loop would fill the log). Loopback (127.0.0.x, [::1], [::ffff:127.0.0.x]) is exempt from both lists (7.25.4 exempted only 127.0.0.x, and only from the allow-list). In 7.25.4 only the allow-list was asked at accept: a denied ip was refused only at the login of a gate that authenticates, so a gate that does not (an MQTT or IoT field port) built its channel and ran its protocol. C_UDP_S asks both lists for every datagram in the same way: every drop is counted in the new stat rxRefusedMsgs, and said on the transition -- the first drop of each cause is a WARNING (“UDP_S: Ip denied, datagram dropped” / “UDP_S: Ip not allowed, datagram dropped”), then at most one a minute per cause, with dropped (since the last WARNING), rxRefusedMsgs and next_warning_in_ms (the source of a datagram can be forged, so a WARNING per datagram would let a peer fill the log). 7.25.4 never read its documented only_allowed_ips, and heard every peer. See “Upgrade steps”. Tests c_tcp_s_ip_lists, c_udp_s_rx.

• An ip-list entry is kept in the form a peer is looked up by. The add- / remove- allowed / denied ip commands read the text with inet_pton() and store its canonical form (2001:DB8::1 -> 2001:db8::1, ::ffff:203.0.113.7 -> 203.0.113.7, fe80::1%eth0 -> fe80::1%2); the answer says it (“<role^name>: ‘2001:DB8::1’ stored as ‘2001:db8::1’”). They refuse a text that is not a numeric ip (a host name, a port, brackets, an interface on an address that is not link-local), with the cause. A link-local address in allowed_ips needs its interface, and matches that interface only; in denied_ips one without its interface is denied on every interface. remove- accepts any form of the ip, and answers -1 for an ip that is not in the list (“<role^name>: ip ‘<ip>’ is not in denied_ips”). Up to 7.25.4 the text was stored as typed and the command answered success, so 2001:DB8::1, [2001:db8::1] or 203.0.113.7:443 were listed and never matched a peer: the operator believed an ip was banned, and it was not. The stored lists are normalised at the first start (see “Upgrade steps”). Test c_tcp_s_ip_lists.

• C_IEVENT_SRV: a remote peer no longer chooses how its subscription is delivered. Of the __config__ of a peer’s subscription only __first_shot__ is kept; __hard_subscription__, __own_event__, __rename_event_name__ and any other key are removed, with a WARNING (“SUBSCRIBING config keys a peer may not set, ignored”, with keys). Up to 7.25.4 a peer could make its subscription hard: it outlived the session and reached the next user of the static channel, past any check of who that user is; with __own_event__, a delivery that failed stopped the publish before later subscribers got it. The close of a channel now removes every subscription the channel made, hard or not. Test c_subscription_authz (a client asks hard, own, rename and first_shot).

• C_IOGATE: a channel_name that does not match every channel no longer hangs the yuno. view-channels, enable-channel, disable-channel, trace-on-channel, trace-off-channel and reset-stats-channel looped for ever on the first channel that did not match (7.25.4 too): the event loop was blocked, and the process ignored SIGTERM. With enable_command_authz off (the default), any authenticated peer that reached an iogate could do it, the agent’s own __input_side__ included. A channel_name that is not a valid regular expression answers “<role^name>: channel_name is not a valid regular expression: ‘<re>’” (it answered “regcomp() failed”). Test c_subscription_authz.

• gobj-c: the authzs trace no longer reads a kw the checker has freed (7.25.4 too): with the trace on, every authz check printed the kw after the checker had released it, a use-after-free. The trace now holds its own reference. Test c_subscription_authz.

• An IPv6 peer can be listed. is_ip_allowed() / is_ip_denied() key a peer by its ip without the port, for IPv6 too ([2001:db8::1]:443 -> 2001:db8::1) and for an IPv4 peer seen by a dual-stack socket ([::ffff:1.2.3.4]:80 -> 1.2.3.4). 7.25.4 cut the port at the first :, so every IPv6 peer was looked up as "[" and no list could name it.

• The subscription authz is enforced, behind a gate that is off by default. New yuno attribute enable_subscription_authz (SDF_RD, default false, apart from enable_command_authz). With it on, an external subscription (through C_IEVENT_SRV, whose user C_AUTHZ set) to an event flagged EVF_AUTHZ_SUBSCRIBE needs the permission of the publisher’s gclass whose alias is __subscribe_event__, or else the global __subscribe_event__. C_NODE flags its five EV_TREEDB_NODE_*, and C_TRANGER its realtime feed EV_TRANGER_RECORD_ADDED, and each puts that alias on read: with the gate on, a peer needs read on the treedb or tranger service to get its feed (for C_TRANGER, the permission open-rt already asks). Every other public output event in the tree was checked, and none carries data a peer could not reach otherwise (the table is in YUNO_AUTH.md §4.6). A refusal is an ERROR (MSGSET_AUTH, “No permission to subscribe event”, with the service, the event, the permission and the user); the subscription is not made and the channel stays open. An internal gobj_subscribe_event() is never checked. In 7.25.4 the check was commented out: the EV_TREEDB_NODE_* feed of a treedb went to any authenticated user, and a user without read could subscribe to a C_TRANGER feed with no filter and get every record of the realtime lists other users opened. Nothing changes until a yuno sets "yuno": {"enable_subscription_authz": true} in its config; that needs a C_AUTHZ role model (the checker is fail-closed), and every user of a treedb GUI then needs read on the services it watches (a refused GUI keeps its session and gets no live updates). YUNO_AUTH.md §4.6. Test c_subscription_authz.

• libjwt (vendored): the jwks_* keyring getters (jwks_item_get(), jwks_error_any(), jwks_error(), jwks_error_msg(), jwks_error_clear()) accept a NULL set, as upstream’s do: jwks_item_get(NULL, 0) crashed. So do jwks_item_count() (0), jwks_find_bykid() (NULL, also for a NULL kid), jwks_item_add() (1) and jwks_item_free_bad() (0), which upstream does not guard either: they carry local guards (// ArtGins: NULL-safety, beyond upstream, listed in kernel/c/libjwt/README.md). C_AUTHZ never passed a NULL set. Test libjwt/test_jwt_alg_confusion.

Data loss and integrity¶

• C_AUTHZ disable-user, enable-user and set-max-sessions ERASED the user’s local password (since 55266cbb5, 2025-11): they read the user without the hidden credentials column and wrote the whole view back. They write only {id, <field>}.

• gc-assets with a snap ACTIVE took the assets of live nodes written after the snap (since 7.18.1): memory holds the snap’s photo. The gc refuses while any snap is active in the tranger. A refused gc takes no asset row; gc-assets still sweeps (and reports) orphan blobs, the bytes no asset row names. The library’s treedb_gc_files() takes nothing on a refusal; the new treedb_gc_files2() returns the report.

• Damaged keys. A key damaged on disk (an md2 that cannot be opened or read, a record whose content cannot be read) makes every load of the key fail (load_failed): a row or content that cannot be read fails the load that meets it, and an md2 the cache build cannot count flags the key at the open, also after a restart. The flag of a file is cleared when the file reads again (an append into a file still unreadable is refused). A keyless tranger2_open_list() still loads every readable key and opens its realtime feed, and reports the failure as load_failed / load_failed_keys. treedb remembers those keys and refuses what memory would answer wrong: a create of such an id (it would shadow the stored record); shoot/activate and the snapshot-guarded deletes when __snaps__ is partial; gc-assets when a topic with a file column or __assets__ is partial; a delete of a node, forced or not, whose hooks hold a topic that did not load whole (“Cannot delete node: a topic its hooks hold did not load whole, a child that did not load may hang from it”; 7.25.4 deleted it, and a child that did not load kept naming it). treedb_delete_instance() refuses when it cannot read every row of the key, and the asset snapshot guard fails closed when it cannot read. Recovery procedure in treedb.md (“A topic that did not load whole”), from least to most destructive.

• msg2db: an id whose history did not load whole used to serve an older message as current. It is now reloaded newest first, up to the damage: a pkey2 whose newest message comes after the damage is served as before; one whose newest message is in the damage or before it is ABSENT (its state is unknown) until its next message -- unless the damaged file is the one new messages go to (the current period’s file; the db_history trangers use one file per YEAR): then every new message of that id is refused (msg2db_append_message() answers NULL) until the file is repaired (treedb.md) or the period changes, and a second ERROR says so. A torn last md2 row is not damage (below, “An md2 that ends in a part of a row”). An ERROR names the id with served=N, and the new msg2db_id_incomplete() tells “unknown” from “none” while the msg2db stays open. For the db_history alarms of the projects (wattyzer, yunovatios, estadodelaire, hidraulia), until an absent alarm’s next message: a device that reports it active gets it announced as new (a notification may repeat), a clear that was in the unread message is not announced, and msg2db_list_messages() leaves it out. tr_msg2db.md shows how a consumer can use msg2db_id_incomplete() to avoid the repeat; no project repo was changed.

• An append that was never acknowledged is not damage. When the md2 of an append cannot be opened or created, or its seek or write fails, the content written for it is truncated back, BEFORE the critical log (“Cannot append record, its md2 file cannot be opened: its content was cut back” for the open) (with the default on_critical_error the process exits there, and 7.25.4 left the bytes behind). An md2 with 0 rows beside a non-empty .json (a kill or a power cut between the two writes) is ignored with a warning, and its key loads (7.25.4 ignored its rows too, without a warning).

• An md2 that ends in a part of a row (a power cut during the 32-byte row write) is cut back to whole rows by the master when the file is first examined, with one WARNING (“md2 file of the key ends in a part of a row: an append that was never acknowledged was cut back”, with old_size / new_size); the key loads whole and appends go on. An append that meets such an md2 cuts it back the same way before it writes its row, so a row always starts on a row boundary; if the cut fails, the append is refused with a CRITICAL (“Cannot append record, its md2 file ends in a part of a row that cannot be cut back: the append is refused”). The cut removes only the part of a row after the last whole row, never an acknowledged row, and only when the last whole row and the row before it are good (each names one whole record of the content, in order: one json value and its NUL, or only zeros for a deleted instance), and the end-aligned 32 bytes, read as a row, neither end the content nor name a whole record. A replica reads only the whole rows and writes nothing. 7.25.4 logged a CRITICAL (“Cannot read last record, md2 file corrupted”) and left the whole file out of the key, on a master and on a replica: the acknowledged rows of that file were missing from every load, and nothing failed. A replica also did this when it caught a live master mid-write.

• An md2 that must not be cut is flagged. An md2 that 7.25.4 kept appending into after a torn row (its later rows off the row boundary, with or without content after its last row) is NOT cut, on a master or a replica: it is flagged (load_failed, appends refused) with a CRITICAL (“md2 file of the key ends in a whole row that is not on a row boundary: written by 7.25.4 after a torn row; not cut, repair it by hand”, with a cause). The check of a node and the repair are in “Upgrade steps”. An append that meets such a file refuses (“...that must not be cut back: the append is refused”) and flags it in memory at once (ERROR “md2 file of the key flagged unreadable at an append: every load of the key says load_failed”); with the default on_critical_error the yuno then exits at the CRITICAL of the refused append. A check that cannot RUN (the .json cannot be opened or read, no memory) refuses the append (“Cannot append record, the torn tail of its md2 file cannot be checked now: the append is refused, the file is not flagged”) and does not flag the file; the next append checks again. At an open the file is still flagged. A candidate range larger than the largest memory block of the reader is read in parts of 64 KiB, never allocated whole: a NUL before its end still says it is not a record, and one whose only NUL is its last byte is never cut on -- the file is flagged (it can be a record written by a yuno with a larger MEM_MAX_BLOCK, which is set per yuno).

• A record with a NUL in a string (json_dumps() writes it as \u0000) is read back. 7.25.4 took it at the append, and every read of it failed with a CRITICAL (“Bad data, anystring2json() FAILED.”) and handed the record to the callback as NULL. A read that fails now logs “Bad data, the content of the record is not json”, with the jansson error and position.

• A short write of topic_var.json / topic_cols.json, or of the zero wipe of tranger2_delete_instance(), is logged as a short write (“...short write: the file size limit or the disk is full”), not with a stale errno (7.25.4: “Cannot write in json file” for the json files, “write() zero payload FAILED” for the wipe).

• A read that returns fewer bytes than asked logs “... short read” with read / expected (it logged “read FAILED” with a stale errno); a short write likewise logs “... short write”. A read error or short read of an md2’s first or last row at the cache build flags the file (it went on with a zeroed row).

• A treedb write whose save fails is taken back in memory. In 7.25.4 treedb_update_node(), treedb_link_nodes(), treedb_unlink_nodes(), treedb_autolink(), treedb_clean_node(), treedb_replace_links() and the child unlinks of a forced delete changed the node (fields, fkeys, parent hooks) before the save and kept the change when the save failed: a read then answered a value the disk never had, and a retry of the same write found nothing to write. Now the node goes back to what the disk has, and the call answers NULL or -1; a write taken back tells no event. treedb_autolink(), treedb_clean_node() and treedb_replace_links() answer -1 when the save fails (7.25.4 ignored it); a link or unlink that fails part way is taken back whole. Link and unlink events, and the parent’s EV_TREEDB_NODE_UPDATED in the compatible mode, are told only after the child is saved, in the same order among themselves (7.25.4 told the link events before the save). A write that is taken back puts every child back in its place in the hooks of its parents (list and dict hooks), in every instance of the parent that held it, each in its place (a topic with a pkey2 has several instances of one id, and an unlink takes the child out of all of them), and a stale fkey ref it removed (its hook gone, or re-pointed to another column) goes back into its field alone, never linked. When memory cannot be taken back whole, an ERROR says so: “A write that did not reach the disk could not be taken back whole in memory: the links in memory differ from the disk until the treedb is opened again”. treedb_autolink() refuses a ref whose hook fills another column than the one the ref arrives in (“fkey reference: its hook does not link into this column”), as treedb_replace_links() does; 7.25.4 linked it through the other column.

• A forced treedb_delete_node() that is refused changes nothing. A child that cannot be saved unlinked stays linked (“Cannot delete node: still has down links”), a key that cannot be deleted refuses the delete too, and the children already unlinked are put back and saved again while the node keeps its parents. In 7.25.4 the parent was deleted while a child on disk still named it, and a delete refused by its key left the node unlinked in memory and every child unlinked on disk. A child that cannot be put back stays unlinked, in memory as on disk, with an ERROR (“A refused delete cannot put back a child it had unlinked: the child stays unlinked, in memory as on disk”), and the events of its unlink are told. A forced delete tells the events of its unlinks after the node has left the indexes and before EV_TREEDB_NODE_DELETED, and until it returns treedb_save_node() refuses the node (“Cannot save a node that is being deleted”): a subscriber that saved it from one of those events could bring it back on disk.

• treedb_delete_instance() answers -1 when a tombstone fails, and keeps the instance. 7.25.4 tombstoned the rows newest first, went on after a failure, answered 0 and dropped the instance, which came back at the next open from an OLDER row. The rows go oldest first and the first failure stops the delete (“Cannot delete instance, a row of it cannot be tombstoned: the instance stays, its newest rows alive”); the older rows tombstoned before it are gone from the history.

• A delete of a node with several instances (a pkey2 topic) looks at all of them. treedb_delete_node() deletes the key, every instance of it, but counted and unlinked the children and the parents of the node it was given alone (7.25.4 too): a child of another instance was left naming a key that is gone (“Node not found” at the next open), and another instance stayed in the hook of its parent, so a forced delete of that parent saved it back into the deleted key and the node was back after a reopen. The children of every instance are counted (without force the delete is refused) or unlinked and saved (with force); every other instance that a parent’s hook holds refuses a delete without force, and with force it leaves that hook. A refused delete puts all of it back. The instances of a child that name the key and that no hook holds (a non-primary instance that nothing links) are counted too: without force the delete is refused (“Cannot delete node: has down links”, now with children and unheld_instances), and with force their ref is cleared and saved first, and put back if the delete is refused (7.25.4 left them naming a key that is gone). The newest record of each key that those saves and the unlinked children touch stays on the instance that wrote it, so the next reload takes the same primary as without the delete (in 7.25.4 the child that a forced delete unlinked last became the primary of its key at the next reload, and a new instance created since lost to it).

• treedb_delete_instance() takes the instance out of the hooks of its parents, and hands its children to the primary (7.25.4 did neither). A non-primary instance sits in a hook when it is linked into a slot that does not hold the primary (an array hook, or the empty hooks of a new parent instance): a delete of that parent without force was refused for an instance that was gone, and a forced one saved the instance back -- its newest row, the primary of its key after a reopen. The children that a deleted parent instance held hung from no visible parent until a reload. Now the instance leaves every parent hook, the primary takes its place where it names that parent too, and the children go to the primary’s hooks, where a reload puts them. Nothing is written.

• After a restart, a pkey2 lookup of a node’s primary returned a copy of it (7.25.4 too). The load built the slot of the primary’s own pkey2 value from its record as a second object, with no links, until the first save of the primary. An update through the instance lookup (treedb_get_instance(), or C_NODE’s update-node when the primary does not match its filter) changed that copy: the primary kept the old values, and its next save wrote them back over the new ones and freed the copy while the caller still held it. C_NODE’s delete-node with a pkey2 value took the copy for another instance and tombstoned the rows of the primary’s version before deleting the key; when that delete was refused (a link, without force), the node came back at the next open at an older version, without its links. The load now puts the primary node in that slot: one instance, one node, with its links. A new instance still does not become the primary in memory; the reload makes the newest record the primary, as before.

• treedb_save_node() refuses a node that no index holds (ERROR “Cannot save a node that no index holds: its record would bring back what was deleted”): a deleted key or instance still reachable through a pointer that a hook or a caller kept. In 7.25.4 such a save wrote a record into the deleted key, and the node came back at the next open. Test test_tr_treedb_delete_instance (every case of these five bullets, each red before its fix).

• treedb_save_node() refuses a node whose pkey2 value was changed in place (ERROR “Cannot save a node whose pkey2 value changed in place: its record would be another instance”, with pkey2_name, old_value and new_value): a caller that wrote a new value of a pkey2 column into the node and saved it. In 7.25.4 the save wrote a new instance on disk while memory kept the node in the slot of its old value; when the new value was another instance’s, the node also took that instance’s slot, the primary’s included. Change a pkey2 value with treedb_update_node(), which refuses it as in 7.25.4, or create the new instance. A node that no slot of a pkey2 holds is saved as before. treedb_create_node() indexes the pkey2 value its record holds (a column default, a converted value); 7.25.4 indexed the raw kw value, so the instance of a defaulted value was missing until a reload. test_c_node_link_events test 21 asserts the invariant C_NODE’s delete-node relies on: a pkey2 lookup of the primary’s own value returns the primary, before and after a reopen. It holds with more than one pkey2 too (a save no longer re-points a slot that the primary holds, where a second pkey2 took the primary’s slot of the first), and for a key with instances and no primary (below, a snap).

• A reference is never cut in silence. 7.25.4 wrote topic^id^hook into char[NAME_MAX] and decoded it into parts of NAME_MAX with no check. A reference with a part that cannot be decoded back is refused and nothing moves: built, “Cannot build the reference of a node: a part of it is too long, or holds a ‘^’”; decoded, “Wrong reference: a part of it is too long”. treedb_create_node() refuses, for a topic with hooks, an id holding ^ (“Invalid ‘id’: it holds a ‘^’, the separator of a reference”) or of NAME_MAX bytes or more (“Invalid ‘id’: too long to be part of a reference”); a topic without hooks keeps any id.

• A delete of a parent no longer leaves a child pointing at a node that is gone. A topic without hooks keeps any id, also one with a ^ or one of NAME_MAX bytes, and such a child can hang from a hook like any other. The delete guard now counts every child a hook holds (count_node_children()), so a delete without force is refused (“Cannot delete node: has down links”) and a forced delete unlinks the child. In 7.25.4 a dict hook did not count a child whose id holds two ^: the parent was deleted, forced or not, and the child’s fkey named a node that is gone, also after a reopen (“Node not found”). The guard no longer builds a reference string for each child only to count them (that change alone takes 2-4% off delete_parent, on top of the ~6% against 7.25.4; see “Performance”). Test test_tr_treedb_hook_hygiene (test_children_without_ref()). The refs / hook_refs option of a hook lists every child, also one whose id holds a ^ or is NAME_MAX bytes long ("users^a^b"); in 7.25.4 the reference of a long id was cut in silence, and named another node or none. decode_child_ref() refuses such a reference, and logs why.

• A hook tells two topics apart. 7.25.4 tested hook membership by the bare id: the group x after the user x was a skipped duplicate in a list hook (its fkey written all the same) and took the user’s place in a dict hook. A list hook holds both; a dict hook refuses the second (“Cannot link, the dict hook holds a node of another topic with this id”), a load keeps the first (“A dict hook holds a node of another topic with this id: this link is not loaded”), and an unlink does not delete the other topic’s entry.

• C_NODE update-node with autolink is ONE write (the new treedb_update_node_and_links()): fields, links and save; a failed save takes all of it back and tells nothing. In 7.25.4 it was three calls, and a failed save left memory with the fields and links, with EV_TREEDB_NODE_LINKED told. It is also what C_AUTHZ does when it creates a user with a role.

• The repair of several active snaps at open keeps a snap active in memory when its deactivation cannot be saved (7.25.4 made it inactive in memory only), and a replica does not try it.

• A link to a parent whose id cannot make a reference (an id of NAME_MAX or more, or holding ^, loaded from an older store) is refused and nothing moves (the “Cannot build the reference of a node” above); in 7.25.4 the reference was cut, the link answered 0, and it was lost at the next open. A save that meets a wrong reference in an fkey column leaves out that reference alone, and logs it: it saved the record without the whole column, so the valid links of the column were lost at the next open (7.25.4 too).

• An unlink clears the parent’s ref in every instance of the child (7.25.4 too). A topic with a pkey2 has several instances of one key, and each carries the fkey it was saved with; the unlink cleared the ref only in the instance it was given, so the other instances still named the parent, and a reload linked them back. Now every other instance that names the parent is cleared and saved first, and the child the unlink was given last, so the child’s record stays the newest; if any of those saves fails, everything is put back and saved again (once each, in the order saved, and the newest record of the key goes back to the instance that wrote it), and the unlink answers -1. A file column is left alone: each instance holds its own asset. Test test_tr_treedb_delete_instance.

• A stale ref in a string fkey column is removed (7.25.4 too). A ref whose hook was renamed or re-pointed is removed from the child by the first relink, clean or forced delete; in a column whose fkey is a single string, the removal wrote the value through kw_set_dict_value(), which kept the old value (see “Agent, gobj-c and tools”), so the clean and the forced delete of such a child failed for ever (“Cannot clean the links”). Test tr_treedb_hook_rename (a string fkey with a renamed hook, clean and forced delete).

• With a snap active, the create of a key that the snap does not hold takes the slot of its value (7.25.4 too). A key created after the snap has instances in the secondary indexes and no primary in memory; its create made a second object for the same instance, and C_NODE’s delete-node of that key then went half way (“delete_primary_node() FAILED”, then “Node not found”). A create that makes the primary of such a key now takes the slot of its value, so the slot of the primary holds the primary. A delete of a key that only the secondary indexes hold no longer logs “delete_primary_node() FAILED”. Test test_tr_treedb_delete_instance.

• gc-assets keeps the asset that a non-primary instance names (7.25.4 too): only the primaries were read, so the gc took the asset of an older instance that still names it. Test test_tr_treedb_delete_instance.

• A relink of one instance of a child no longer takes a sibling instance out of a dict hook (7.25.4 too): a move of the instance to another parent (treedb_link_nodes()) removed the slot of the old parent by the child’s id, so a sibling instance that still named that parent left the hook with it. The slot is removed only when it holds that very node. A direct treedb_unlink_nodes() still takes every instance out, and clears the parent’s ref in each (above). The two normal cases are no longer errors: the hook holds another instance of the child, or the child is a non-primary instance that nothing holds (7.25.4 logged the ERROR “Child data not found in ... parent hook”; one of the list-hook cases said “dict”, and now says “list”). A new instance of a child held through a list hook no longer warns “Duplicate fkey on load, deduping parent hook”. Tests test_tr_treedb_delete_instance (test_relink_through_a_dict_hook_keeps_the_sibling, a dict hook over a string fkey).

• A snap shot no longer chooses the primary of the next reload (7.25.4 too). A shot that clones a primary already tagged by an earlier snap made the clone the newest record of its key, so a new instance created since (e.g. by an install-binary) lost to the photo at the next reload. The newer instance’s record is written again after the clone. Test test_tr_treedb_delete_instance.

• A link that fills the hook of a new instance no longer warns “Parent ref already in child fkey, skipping duplicate” (7.25.4 too). The ref names the parent’s KEY, which all its instances share, so it is already in the child’s fkey when a new instance of the parent takes a child that an older instance holds, or when a new instance of the child inherited it: every create-yuno of a new release warned for its configuration (and for its binary, when the binary was installed after the old release linked it). The link fills the hook of the new instance and nothing else. The warning stays for a real duplicate: the same pair linked twice. When no other instance of the parent key explains the ref (none holds the child, and this one is not a new instance with an empty hook), the hook LOST a child its fkey names: the link repairs it and warns “Parent hook had lost a child its fkey names: repaired” (with the topic, parent id, hook and child id); 7.25.4 repaired it under the duplicate warning. Tests test_c_agent_find_new_yunos (its fixture now links binaries and configurations as create-yuno does) and test_tr_treedb_hook_hygiene (a hook emptied by hand on a parent with one instance warns once).

• Lost lock. A master that lost its lock while stopped (another process took the store) writes nothing: every write path, including the three md2 flag rewriters (tranger2_write_user_flag, tranger2_set_user_flag, tranger2_set_system_flag, which on a replica logged a CRITICAL and exited), retakes the lock first or refuses. If another process holds the lock the revive is a CRITICAL at on_critical_error, as at startup; any other lock failure demotes the tranger to replica (master false, master_lost true) with an ERROR and the yuno keeps running -- watch for it. C_TRANGER’s master reads the effective state, and so do the new master and stopped fields of C_TREEDB’s treedbs rows.

• topic_var.json (the rowid counter) and topic_cols.json are replaced through a fresh .new file (O_EXCL|O_NOFOLLOW) and a rename, never rewritten in place; a topic_version change fsyncs, writes cols before var, and on a failed write leaves the version on disk unchanged.

• tr_queue and tr2q_mqtt: a queue whose key did not load no longer saves a first_rowid past the pending messages (they were skipped for ever, even after the md2 was repaired), and its periodic backup is refused until a load reads every pending message.

• C_NODE link, unlink and delete are refused on a replica before memory moves (direct C callers; the commands already checked).

• A key directory that cannot be LISTED (EMFILE, EACCES, ENOMEM, or no memory for an entry of the listing) loaded in 7.25.4 as an EMPTY key: the load said nothing (only the helper’s ERROR “Cannot open directory” when the directory could not be opened; nothing at all for a lost entry). After a restart a treedb node was absent, a create of its id was accepted over the history nobody read, and an append counted its row as the first of its file. The key is flagged ("unlisted", ERROR “key directory cannot be listed when its cache was built: every load of the key says load_failed”): every load of it says load_failed (a keyless list names it in load_failed_keys, so treedb’s create guard fires), and an append lists the key again first -- refused while it still cannot be listed (“Cannot append record, its key cannot be listed: ...”). A topic whose keys/ cannot be listed is not opened (tranger2_open_topic() answers NULL, “Cannot open topic: its keys cannot be listed”; the next open tries again); it opened with no keys. find_files_with_suffix_array(), walk_dir_array() and get_ordered_filename_array() answer -1 with the listing empty when an entry cannot be kept (7.25.4 dropped the entry, or kept it as NULL, and answered 0), and the last two also when the ROOT is a directory that cannot be opened (7.25.4: 0 and an empty listing; a root that is not a directory already answered -1). A readdir() that fails is a failed listing too, in those three and in walk_dir_tree() (-1, “Cannot list directory, readdir() FAILED” / “Cannot read directory, readdir() FAILED”): 7.25.4 took it for the end of the directory, and timeranger2 could load a key without some of its md2 files. A subdirectory that cannot be opened is skipped, with a WARNING (“Cannot open subdirectory, it is skipped”; 7.25.4 was silent for EACCES and ENOENT), only for EACCES, ENOENT, ENOTDIR and ELOOP; for a transient cause (EMFILE, ENFILE, ENOMEM, EIO), or when it cannot be read, it fails the walk (7.25.4 skipped it and answered 0 with a short listing), and so does an entry whose lstat() fails for a cause other than EACCES / ENOENT (7.25.4 logged it and dropped the entry). walk_dir_array() with a NULL pattern lists every entry (7.25.4 crashed), and a root of walk_dir_tree() that cannot be opened is always logged (an EACCES root answered -1 with no log). On a filesystem without d_type the keys are asked with lstat(): a symbolic link in keys/ is not a key (7.25.4 followed it with stat(): a key with another key’s records); an lstat() that fails with EACCES takes the entry as a key, as DT_DIR does, and one that fails for another cause than ENOENT fails the listing of the topic’s keys (“Cannot list the keys of the topic, stat() FAILED”; 7.25.4 dropped the key in silence), so the topic does not open. find_files_with_suffix_array() without d_type lists an entry whose lstat() fails with EACCES, as the entry type does (7.25.4 skipped it with no log: a key directory of mode r-- loaded EMPTY and unflagged). rmrcontentdir() and rmrdir() fail on a readdir() error, with a log (7.25.4: rmrcontentdir() answered 0 in silence, and rmrdir() blamed the rmdir() with ENOTEMPTY). Tests timeranger2/test_unlistable_dirs, tr_dt_unknown (cases 4 and 5: a link in keys/, a key directory of mode r--), helpers/test_dir_array_nomem, helpers/test_dir_read_error (case 18: an lstat() that fails with EACCES without d_type).

• A flag goes when its cause goes, on a replica too. A load tries the flags of its key first: it lists an unlisted key again when its directory changed since it was flagged (ctime) or opens now after an open failure (INFO “key directory listed again: its files are counted, and the key is not flagged”), and counts a flagged md2 again when it changed since it was flagged (ctime or size) or opens now after an open failure. A flag that looks unchanged is not tried, so a damaged key or file is not read and logged again at every load; a directory whose readdir() recovers without changing stays flagged until it changes, an append lists it, or the topic is opened again. A replica never appends: its loads are what clear its flags. The notification of an append (the rt_disk follower) lists the key first: its file’s rows are published with their rowids in the whole key (for a key the replica could not list, 7.25.4 counted the notified file alone as the whole key, and the feed got the key’s 4th row with rowid 1), and nothing is read while the directory cannot be listed (“New records of the key not read: its directory cannot be listed”). Tests timeranger2/test_unlistable_dirs (cases 4, 5), timeranger2/test_unlisted_relist_once.

• A queue backup that FAILED killed the queue (7.25.4 too): trq_check_backup() / tr2q_check_backup() took the NULL of tranger2_backup_topic() as the queue’s topic and answered 0 -- every read logged “What topic?”, every ack answered -1, no backup happened again. tranger2_backup_topic() opens the topic again after any failure that follows its close (WARNING “Backup of topic failed: the topic is opened again as it was, not backed up”; it was left closed), no longer leaks topic_var on a failed rename(), and logs a missing topic directory (“Cannot back up topic, its directory not found”; it returned in silence). The queues take the topic again and answer -1 (“Queue backup failed: the queue goes on in its topic, not backed up”). A backup whose new topic cannot be created after the move removes what the create left, moves the backup back and opens the topic again (7.25.4 left the queue with no topic, and never tried the backup again). This works in every tranger: the create of a backup runs with the exit bits of on_critical_error off, so the MQTT broker’s queues (LOG_OPT_EXIT_ZERO) no longer exit at the CRITICAL of the failed create, before the backup is moved back, with the messages left in <queue>.bak. When the backup cannot be moved back, a CRITICAL says where the data is (“Backup of topic failed, and the backup cannot be moved back: the data of the topic is in the backup”). A queue whose topic cannot be opened again either (“Queue backup failed, and the queue has no topic”) takes it again by name as soon as it can be opened: at the next trq_check_backup() / tr2q_check_backup(), read, ack or load (INFO “Queue topic taken again”); until then those calls fail: only the first one says it (ERROR “Queue without topic, it cannot be opened”), the next ones ask the disk quietly and log nothing (the broker calls tr2q_check_backup() every second per session). A topic the tranger has open again (an append opens it by name) is taken as it is. Otherwise the open is tried again only when what stopped it may be gone: a topic_desc.json that loads as no json once it changes (each change tried once, so a broken file is said once as well); a file that cannot be opened or a keys/ that cannot be listed (EACCES, EMFILE, EIO) once both can; anything else once topic_desc.json or keys/ changes. Test tr_queue/test_tr_queue_backup_failed (cases trq_broken, tr2q_broken: 3 open errors each; trq_keys, tr2q_keys: a keys/ of mode 0).

• A new topic is created whole or not at all. When any part of a NEW topic cannot be made (its directory, topic_desc.json, topic_cols.json, topic_var.json, keys/ or disks/), tranger2_create_topic() removes the directory it made, keeps nothing in memory and answers NULL (CRITICAL “Cannot create topic: it is not whole, what was made is removed”, at on_critical_error, logged after the removal); the next create starts again from nothing. The failures before it are logged without the exit bits, so under LOG_OPT_EXIT_ZERO (C_TRANGER, C_TREEDB, the broker’s queues) the process exits only once what was made is removed. In 7.25.4 each failure was logged and the create went on: a topic without its keys/ or disks/ was opened and returned as created (a replica had nothing to watch), and a queue backup took that half topic as the queue’s new one, answered 0 and left the messages in the .bak. Test tr_queue/test_tr_queue_backup_failed (the keys cases).

Scans and lists (timeranger2)¶

• tm order is marked: in topics created from now on (or migrated with the new tranger2_mark_tm_order()), a file that receives a record out of tm order gets a <file>.tm_unordered marker, written BEFORE the md2 row (a marker that cannot be written is retried at the next append to that file). A marked file’s tm range is read from all its rows; in a file known to be in tm order a row past the range ends the scan of that FILE (not of the key). A marker name that does not fit makes the file be read whole (logged). In 7.25.4 a reload and a replica took a file’s tm range from its first and last rows: a tm query left out a file whose rows are not in tm order, and its matching rows were missing from the answer. The <file>.unordered marker of a late __t__ (every topic, as in 7.25.4) is also written BEFORE the md2 row and retried at the next append to the file (mark_file_before_append()); 7.25.4 wrote it after the row, so a process that died between the two left a file whose t goes back with no marker. tranger2_mark_tm_order() fails, and does not mark the topic, when a key directory cannot be listed.

• tranger2_list_topic_names() answered [] with no log when the store could not be listed (7.25.4 too): the MQTT broker’s list-queues and clean-queues answered an empty list with 0. It logs (“Cannot list the topics of the store”, with the errno of the failure) and answers NULL; the new mark-tm-order all=1 answers -1, and so do list-queues (“<role^name>: cannot list the topics of the store, see the log”) and clean-queues (“<role^name>: cannot list the topics of the store, nothing cleaned, see the log”). list-queues queue=<name> answers -1 for a queue that cannot be opened (“<role^name>: cannot open the queue ‘<name>’, see the log”) and for a queue whose messages cannot all be read (the partial list, with “<role^name>: the messages of the queue ‘<name>’ cannot all be read, the list is PARTIAL, see the log”); 7.25.4 answered 0 with an empty or short list. Test c_mqtt/acl.

• A scan steps over the holes a tm filter leaves between files (7.25.4 logged a false “next rowids not consecutive” and lost the rows after the hole).

• After delete_key the iterators of that key drop their segments (7.25.4’s segment stamp could miss a key deleted and written again with the same counts). The delete is announced only once its directory is gone: the key directory is removed first, and a removal that fails announces nothing, reads the key’s cache again from what is left, and indexes the key again in its filtered iterators (ERROR “Cannot index the key again after its files changed: the filtered iterator is empty” when it cannot). A key directory whose stat() fails with anything other than ENOENT answers -1 (“Cannot delete key, stat() of its directory FAILED”), with nothing deleted, dropped from the cache or announced; 7.25.4 answered 0, dropped the key from the cache and announced it, with its files left on disk. Only ENOENT is “not found” (logged, 0, as before). The mirror of the delete to the rt_disk feeds (disks/) logs an opendir() or readdir() that fails (“Cannot tell the rt_disk feeds that a key was deleted, opendir() of disks/ FAILED”, “Cannot tell every rt_disk feed ..., readdir() of disks/ FAILED”); 7.25.4 was silent. The delete itself still answers 0 then. Test timeranger2/test_delete_key_propagation.

• rt disk ids: an empty id and a same-creator duplicate are warnings (peer input) like another creator’s; tranger2_open_iterator() no longer leaks on a bad topic.

Performance, against 7.25.4¶

Measured with the benchmarks under performance/c/ (perf_timeranger2, perf_tr_treedb, perf_c_treedb, perf_rotatory, new in this release, and the yev_loop ones) and the test timeranger2/test_topic_pkey_integer, each linked against the module of 7.25.4 and of this release, run alternated (means of 8, 10, 14 or 20 rounds, some of them on 4 link layouts; RelWithDebInfo with memory tracking, ext4, laptop NVMe). The last fixes (keys that cannot be listed, the delete guard, the schema leftovers, the rotatory newfile callback; then the instances of a delete, the pkey2 load, the readdir failures, the schema order, the audit of a JSON text inside a JSON text; then the pkey2 save guard, the audit’s quote-proof scan, the rotatory exit_on_fail, the directory walks and the queue backups, and the C_UDP_S read buffer; then the instances that follow an unlink or a delete of their parent, the rotatory size limit in bytes, the audit of escaped names, the yev_loop fd close, and the kw of a subscription that rewrites it; then the ring entry a stop reads, the newest record of a key, and the match of a repeated subscription) were measured by an A/B of each change alone, on a machine shared with other builds; the pkey2 load, the C_UDP_S round trip, the publish and the subscribe each with a program written for it (none in the tree). The raw figures, with their spread, are in performance/c/README.md.

• timeranger2.

  • An append costs what it cost in 7.25.4, with the checks this release adds to it (a flagged file, the tm order, a torn md2 tail, a stopped master). The append looks up the cache of its key once, and it searches the cache cell of its file once; cmp_file_ids() compares file ids in place, without snprintf() (new test timeranger2/test_cmp_file_ids). perf_timeranger2, 20 rounds: 400 000 appends into 20 000 files 1733.5 -> 1712.6 ms (-1.2%), 600 000 appends into 30 files of a topic that marks tm order 1635.0 -> 1627.3 ms (-0.5%). test_topic_pkey_integer, appends/s without / with an rt list, averaged over 4 code layouts (n = 80): 7.25.4 220 120 / 166 498, now 221 588 / 167 381 (+0.7% / +0.5%). A single link of each moves up to 2.5% with the address of the libraries after the module (jansson’s json_dumps() is ~40% of an append): see performance/c/README.md.

  • A master opens a store 13% faster (20 000 md2 files: 92 ms -> 81 ms): it finds the order markers in the listing of the key directory it already reads, instead of a stat() per md2 file.

  • Price kept, by decision: a replica’s open is ~19% slower (90 ms -> 106 ms, one more stat() per md2 file): it looks for the markers on disk after reading each file, because a listing taken before could miss a marker the master writes during the open. Creating a topic makes 2 fsyncs and a topic_version change 4 (7.25.4: none; 10 topics created in 119 ms against 3.6 ms, 10 version changes in 232 ms against 1.7 ms); opening an existing store makes none. That is the price of durable topic files: a power cut never leaves a new topic_version over a topic_cols.json that is not on disk.

  • Price until migrated: a tm query on a topic created by 7.25.4 or earlier reads every md2 row of the key until mark-tm-order runs (one minute of 1 key x 30 files x 20 000 rows: 13 ms on 7.25.4, ~392 ms unmigrated, ~7 ms migrated). See “Upgrade steps”.

  • The last fixes (a key or a topic that cannot be listed, a failed backup, the retry of a flag at each load) move nothing out of the noise. 10 alternated rounds, before -> after: 400 000 appends 1927 -> 1874 ms (-2.8%), the master open 89.1 -> 87.1 ms (-2.2%), the replica open 117.1 -> 116.0 ms (-0.9%); the retry of the flags, 6 rounds: -2.8% .. +1.4% on the open, tm query, append and mark_tm_order cases. With nothing flagged it costs two dict lookups per iterator open and one per notification. The fixes after them (a failed delete_key that indexes its iterators again, a key listed again only when its directory changed, a backup whose create fails moved back), 8 alternated rounds: 400 000 appends 1517.6 -> 1526.8 ms (+0.6%), the master open 83.1 -> 83.3 ms (+0.2%), the replica open 136.5 -> 136.2 ms (-0.2%), noise. The whole-or-nothing create came after that run; it changes only the failure paths of a create. The directory walks that fail on a long path or a transient error, and the queue that takes its topic again (8 alternated rounds): the master open 81.17 -> 81.90 ms (+0.9%), the replica open 106.47 -> 106.36 ms (-0.1%), noise.

• treedb writes (perf_tr_treedb, 100 000 operations, CPU time, 4 link layouts): an update in memory 3.92 -> 2.92 us, a saved update 11.75 -> 10.81 us, link+unlink 11.27 -> 11.09 us. An update deep-copied the node, with every child its hooks hold, for the system schema’s check on every treedb; now only on the system schema. A forced delete of a parent with 200 children is ~6% faster (2952 -> 2781 us): it tells its children’s events itself instead of holding two per child. The last fix of the delete guard takes 2-4% more off it: it counts the children instead of building a reference string for each (A/B of that change alone, 12 rounds x 4 layouts: median 3139 -> 3076 us, -2.0%; paired mean -3.9% +- 1.4%). Price: a forced delete of a leaf costs ~1.7% more (53.1 -> 54.1 us, ~1 us): the hold of its events and the kept column that let a refused delete change nothing (the guard fix: -0.5% +- 0.8%, noise). The delete that looks at every instance of its key, and the save guard (A/B of that change alone, 12 rounds x 4 layouts, mean of the 48 paired ratios): -0.1% .. +3.5%, the medians under 1% on the save path and +2.5% on delete_force (one array of the key’s instances per delete), inside a spread of 8-13% per pair: noise. The save guard of a pkey2 value changed in place (A/B of that change alone, 20 alternated rounds, medians): a saved update 10.805 -> 10.836 us (+0.3%), link+unlink -0.4%, create_link_half -0.7%. The benchmark’s topics have no pkey2, so the guard itself does not run there; the pkey2 list it needs is fetched once per save and reused. The unlink and the delete that clear the parent’s ref in every instance of the child key (A/B of that change alone, 12 alternated rounds, paired change): -3.8% .. +1.7%, no loss (a saved update 10.61 -> 10.21 us, delete_parent 3040 -> 2944 us); the benchmark’s topics have no pkey2, and the new scans run only for a child topic that has one. The newest record of each key kept on the instance that wrote it (A/B of that change alone, 12 alternated rounds pinned to one CPU, us of CPU an operation, mean +- standard deviation): a saved update 10.955 +- 0.11 -> 10.947 +- 0.53 (-0.1%), delete_force 73.07 +- 4.1 -> 74.53 +- 5.4 (+2.0%), delete_parent 3308 +- 409 -> 3210 +- 134 (-3.0%): noise. The benchmark’s topics have no pkey2, so there the new code is one lookup per child.

• A pkey2 topic opens faster: the load puts the primary in its own pkey2 slot instead of building a copy of it. 4000 keys x 3 instances, 12 alternated rounds: a reopen 353.5 -> 327.2 ms (-7.4%), an update through treedb_get_instance() 29.4 -> 28.6 us (-2.7%). perf_tr_treedb, whose topics have no pkey2, moves -1.5% .. +0.5% (8 rounds x 4 layouts, noise).

• A JSON file is read whole, then parsed (load_json_from_file(), load_persistent_json(), and tr2migrate): json_loadfd() made one read() per byte, 60 000 system calls for a 60 KB schema.

• C_TREEDB opens (perf_c_treedb, 40 treedbs x 10 topics x 20 columns, seconds for 40 opens, 10 alternated rounds, mean +- standard deviation). Against the C_TREEDB of 7.25.4 linked with the libraries of this release, so both on the new JSON load: the same literal 0.672 +- 0.071 -> 0.613 +- 0.020 (-9%), the first projection (seed) 9.87 +- 0.42 -> 10.84 +- 0.32 (+10%), a newer literal 12.79 +- 0.44 -> 13.89 +- 0.53 (+9%). 7.25.4 with its own JSON load took 1.84 s for the same literal. An open reads only the nodes of __system__ of its own treedb, and parses the literal once: 7.25.4 parsed the same object a second time with parse_schema() (~2.9 ms an open), a check left from the releases that read the schema back from __system__ (a literal that fails now logs its bad column once, not twice). The id-collision check collects the ids only and describes the two elements when there is a collision.

• Price kept, by decision: the last two schema fixes (a literal with other content under the file’s schema_version said at every open, and the move of a rowid-keyed projection before the upgrade record) cost the same literal ~0.9 ms an open: one schema_diff() of the literal against the file and one more lookup of treedbs (A/B of that change alone, 8 rounds, ms an open: 15.33 +- 1.46 -> 16.20 +- 0.66, +5.7%; seed +0.3%, newer literal +1.0%, noise). The same literal is then ~0.648 s for 40 opens, ~4% below 7.25.4 (not measured in one run).

• Price kept, by decision: what an open costs over 7.25.4, measured with probes in the code (ms an open; the probes cover only the steps listed):

  • The same literal, ~0.9 ms, paid by the removed second parse (net -2 ms, ~-1.1 ms with the ~0.9 ms of the last fixes above): C_TREEDB reads and parses the schema file in use (~0.7 ms for a 60 KB file), because what runs is decided against the file, as treedb_open_db() decides it, which reads the file again as in 7.25.4; the id-collision check (~0.1 ms); the records of an apply and of an unfinished projection (~0.04 ms).

  • A newer literal, ~25 ms (net ~22 ms): the record of the projection in progress, written whole with its fsyncs before the first write (~14 ms); the index of the treedb’s nodes of __system__ and the search for orphans (~5 ms); the drafts, __system__ compared with the file in use (~3 ms); the ownership checks of the projection (~2 ms); the schema file in use read (~1.3 ms).

  • The seed, ~19 ms (net ~16.5 ms): the same record (~12.5 ms); the index of __system__, the orphans and the ownership checks (~6.6 ms). The benchmark says more than the probes: +24.3 ms an open for the seed and +27.5 ms for a newer literal ((10.84 - 9.87) / 40, (13.89 - 12.79) / 40), so ~6-8 ms an open is spent outside the steps the probes cover. The record is the crash safety of the projection; the index, the orphans and the drafts keep an operator’s draft from being taken for what a projection left, and the reverse.

• The schema fixes after them (the order of the file in a save, the positions a save writes, a topic raised past what runs, the imposed tie said), 8 alternated rounds on a machine busy with other builds, seconds for 40 opens: the same literal 0.835 +- 0.135 -> 0.857 +- 0.140 (+2.6%), the seed 2.786 +- 0.270 -> 2.913 +- 0.286 (+4.6%), a newer literal 3.012 +- 0.552 -> 2.836 +- 0.252 (-5.8%). Each difference is inside a spread of 9-18%: noise. The only new work on the same-literal path is one topic_var.json read per topic (and its topic_cols.json for a topic that runs ahead of its file). The absolute figures differ from the ones above: another day, another state of the machine.

• rotatory (perf_rotatory, ns for one agent audit record of 300 bytes, 8 rounds): 6 194 -> 554 (see “Agent, gobj-c and tools”); flushed after each record, as the agent audit does now, 7 623 -> 1 475. The last rotatory fixes (the newfile callback for a new file only, the keep_all retry, the fixed names) move nothing: 12 alternated rounds, +0.4% .. +2.3%, each within one standard deviation. Nor do the ones after them (the callback kept when a new file fails to open, no size rotation at a new name, the retry on the monotonic clock): 10 alternated rounds, the medians of audit_record 670 -> 640 ns, audit_record_flush 1 476 -> 1 474 ns, log_record 432 -> 438 ns. The audit of a JSON text inside a JSON text costs +0.22 us a record (6.32 -> 6.54 us to build and write it, +3.5%), only when the kw holds an escaped JSON text; the other records do not move (list-yunos 1.63 -> 1.64 us, run-yuno 5.34 -> 5.15 us, a kw with a plain JSON text 6.31 -> 6.33 us). The scan that finds such a text whatever quotes come before it (6 alternated runs, us a record): the escaped JSON text 8.28 -> 8.41 (+1.6%), a plain JSON text 8.11 -> 8.18 (+0.9%), run-yuno 6.83 -> 6.83, list-yunos 1.60 -> 1.54 (-3.8%). A handle whose later opens are printed instead of ending the process (exit_on_fail, 8 alternated rounds, ns a record): audit_record 553 -> 547 (-1.1%), audit_record_retention 547 -> 545 (-0.4%), audit_record_flush 1 280 -> 1 265 (-1.2%), log_record 386 -> 387 (+0.3%): only the failure paths moved. The size limit compared in bytes (8 alternated rounds, ns a record): audit_record 555 -> 574 (+3.4%, its median +0.9%: three slow rounds), audit_record_retention 564 -> 565 (+0.1%), audit_record_flush 1 310 -> 1 300 (-0.8%), log_record 391 -> 388 (-0.8%), noise. The audit that reads an escaped key as its whole string and a secret value as its whole shell word (10 alternated rounds, us a record): +1.1% .. +1.4%, and list-yunos +6.9% from one outlier round (its median -1.3%). Price: the audit that decodes the JSON escapes of the names and looks for a write-attr in every string of the kw costs every record +2-3% (8 alternated rounds, us a record: list-yunos 1.51 -> 1.55, run-yuno 6.44 -> 6.57, a kw with a JSON text 7.74 -> 7.98, an escaped JSON text 8.05 -> 8.29).

• yev_loop: perf_yev_ping_pong -1.1%, perf_tcp_test4 +1.6%, perf_tcp_test5 -0.8% (8 rounds, noise); the last fixes (a take-back that wakes the loop, a stop without memory) -0.4% on perf_yev_ping_pong (6 rounds, noise), and the src_url of another family -0.2% (148.7 -> 148.4 K msg/s, 6 rounds, noise). C_UDP_S has no benchmark in the tree; the read that takes a new gbuffer when the host keeps the received one was measured with an echo server and a client written for it (64-byte datagrams, 20 000 round trips a round, 8 alternated rounds): 11.88 +- 0.77 -> 11.59 +- 0.35 us a round trip (-2.4%), noise. The close of an fd that takes back the submissions of other events on it (8 alternated rounds): perf_yev_ping_pong 137.8 +- 5.0 -> 140.5 +- 4.6 K msg/s (+2.0%), noise. The entry of the ring cleared when it is handed out, and the cancel of a running stop prepared before the fd closes (6 alternated rounds): perf_yev_ping_pong median 147.7 -> 147.9 K msg/s (+0.1%; one round of 123.0 among 147-153), noise.

• Price kept, by decision: a subscription that rewrites the kw gets its own. gobj_publish_event() gives a subscription with __local__ or __global__ a kw_twin() of the event (its own top level, the values and gbuffers shared); every other subscriber shares the publisher’s kw, as in 7.25.4 (see “Security”). No benchmark in the tree; one written for it, only gobj.o swapped, us a publish (8 alternated rounds at ~250 bytes, 16 at ~20 KB), 7.25.4 -> now:

  • no __local__ / __global__: 1.78 -> 1.78, 3.20 -> 3.21 and 19.86 -> 18.86 (1, 10, 100 subscribers, 250 B); 63.03 -> 62.76, 64.98 -> 64.22 and 79.59 -> 81.28 (20 KB): -5.0% .. +2.1%, noise.

  • __global__ on every subscription: 1.95 -> 2.08 (+6.6%), 3.71 -> 5.93 (+59.9%), 21.76 -> 44.94 (+106.5%) at 250 B; 64.37 -> 63.88 (-0.7%), 65.65 -> 67.54 (+2.9%), 82.44 -> 104.93 (+27.3%) at 20 KB. A twinned delivery costs ~0.23 us whatever the size of the event (a deep copy of the kw would cost ~1.8 us at 250 B and ~55 us at 20 KB). Every C_IEVENT_SRV subscription carries __global__ (the gate’s back-metadata), so a remote subscriber pays it, beside the serialization of the kw it already paid.

• A subscribe matches the kw as it is stored (the fix of a repeated __own_event__ / __rename_event_name__ subscription). No benchmark in the tree; one written for it, only gobj.o swapped, 4 alternated rounds, medians of a subscribe and an unsubscribe, us an operation, before -> after that change: 2000 subscriptions 167.7 -> 158.4 (-5.5%), with __config__ 226.0 -> 218.6 (-3.3%); 100 subscriptions 8.63 -> 8.47 (-1.9%), with __config__ 11.24 -> 10.69 (-4.8%). The publish of the same program moves -3.4% .. +2.7% (medians), noise. The gate’s own subscribe adds one scan of the channel’s subscriptions (at most max_subscriptions), and stores a smaller back-metadata, which every event of the subscription copies: not measured.

• ctest times (build/*.txt, 52 runs of yunetas test from 2026-09-23 10:20 to 2026-09-25 12:26): of the tests whose code did not change after 7.25.4, only test_treedb_schema_fidelity moved more than 10%, 1.14-1.26 s (the 4 runs before the change) -> 1.55-1.81 s (the 48 after it; +36% .. +44%, median 1.19 -> 1.66 s, +39%). It opens four treedbs in four new stores, and its fsyncs (88, ~0.56 s) are the price of the durable topic files and of the projection record. The c_tcp, c_tcp2 and c_tcps tests wait on whole seconds of their retry timers and moved by whole seconds in every period (c_tcp/test2 9-15 s, c_tcp/test3 2-4 s, c_tcps/test1 12-14 s): noise. timeranger2/test_topic_pkey_integer stays at 1.84-2.12 s.

Schemas (C_TREEDB)¶

• A newer C literal wins whole (dynamic-schema treedb, impose off). As in 7.25.4, a literal with a schema_version higher than the schema file in use replaces the whole file; an equal or older literal is not installed and the file runs. New: __system__ is projected from an installed literal whole -- topics, columns and attributes the literal no longer declares are removed from __system__ too (7.25.4 only added and updated). What the literal discards is said in one WARNING (“Schema from C withdrew work on the schema at open”) and exposed as withdrawn_at_open per topic in treedbs rows and saved-schema until the next open: applied (an applied schema never opened), in_use (an applied schema that ran), saved, unsaved (drafts), and left_by_older_release (below). A topic whose columns the literal changes without raising its topic_version keeps running its old columns in the store (tranger2 swaps columns only on a version raise): the open warns.

• A projection says when it is unfinished, and records it. A removal that is refused (a snapshot of __system__ holds the node), or a create, update or link that fails, leaves the projection unfinished: one WARNING with not_removed / not_written and how to finish it (for a removal, delete the __snaps__ row), and a record, saved_schemas/<treedb>.unfinished.json (schema_version, not_removed, not_written, leftovers, draft_kinds, leftover_nodes). While the record exists every open retries the projection (INFO “Completing the projection into system, left unfinished by an earlier open” when the file runs, otherwise “Updating TreeDB schema in system”: a newer literal installed, or an imposed one), the leftovers it names, while they stay as the projection left them, are never taken for an operator’s draft nor reported as withdrawn work, a new unfinished_projection field says it in treedbs and saved-schema, and save-schema refuses (it would publish the removed topic again). A projection that completes removes the record; so does delete-treedb. The record is written whole (one buffer, a .new file, an fsync and a rename, as the record of an apply); one that cannot be read still means “unfinished” (one WARNING at each read, with its cause in error; save-schema refused; retried), and then what __system__ holds over the file is reported as an unsaved draft when the projection completes. A record that cannot be written is kept in memory and written again at every open, and the treedb node says c_schema_version: -1; after a restart the record is “lost” (a WARNING, save-schema refuses, and what __system__ holds over the file is reported, never deleted in silence). The record keeps draft_kinds, so the open that finally replaces a draft reports its kind (a saved draft is saved). A treedbs node never stamped (schema_version 0, no record, a file in use at schema_version 1 or more) is a seed that died: the next open completes it and reports nothing.

• A draft is reported once, by the open that replaces it in __system__, whether it was made before the projection failed or while it was unfinished. The part of a draft a projection could not replace stays a draft (in draft_changed), never a leftover; a column delete that fails after its topic was removed keeps its draft. A topic the operator deleted from __system__ is a draft too: when a newer literal re-creates it, it is reported as unsaved, or saved when a pending save published the deletion. A topic the operator added and did not save is unsaved, also when a save of another topic is pending. An EDIT of a leftover is operator work too: the record keeps leftover_nodes (what the projection left at each leftover), a leftover that differs from it (edited, unlinked, deleted, moved to another topic, linked to one more, or left in no topic) is a draft (draft_changed), and the open that replaces it reports it (a move reports both topics); an unedited leftover is not reported. The record keeps only the attributes a projection writes, and system_schema_version: an id whose write failed (not_written) is taken as left, and a record kept under another meta-schema takes every leftover as left, with a WARNING (“Leftovers of an unfinished projection were kept under another meta-schema: every leftover is taken as left, an edit of one made meanwhile is not told apart”).

• A projection that dies half way invents no operator work. Before its first write a projection plans every write and records the plan (the record of an unfinished projection, with "in_progress": true: planned, target_nodes, replaced_kinds); the projection that completes removes it after its WARNING. A process killed between two writes always leaves that record: the next open takes a node that is as it was, or as the projection writes it, for the projection’s, completes the projection, and reports the drafts it was replacing exactly once, also when the retry is killed too (tests: c_treedb_literal_wins, scenarios CR and DC, a kill at every write). Until then unfinished_projection lists planned and save-schema refuses. The move of a rowid-keyed projection (before 7.13.2) to qualified ids runs first, before the upgrade record is built, so the record names what an older release left at its qualified ids (scenario LQ). It can die at any write and completes at the next open; a move with a failed write says so (WARNING “TreeDB schema ids moved to qualified names only in part: nothing is projected at this open, every open retries the move, save-schema refuses until then (see the errors before this)”), projects nothing at that open, records the projection as unfinished, and the next open moves the rest (scenario LX).

• A projection that 7.25.4 stamped first is completed, and judged node by node. 7.25.4 and earlier wrote the stamp of the treedb node first; a process that died after it left a projection that said it was complete, and it was taken as done at every open. Now it is completed, with impose_c_schema and without it: a column the dead projection did not write gets the literal’s content, and only a NODE (a topic or a column) that differs from both the old file and the literal is the operator’s draft -- a topic with one column written and one not is not reported. A node in no tree that is what the literal writes, and that the old file does not declare, belongs to the dead projection (a create whose link never happened). The record of the completing projection keeps the literal (stamped_base), so a retry after a second crash compares with both again (tests: c_treedb_literal_wins, scenarios SE, SH, SI, SJ, SK, O4C, O4A, O4X).

• The first open by this release reads what an older release left. New record saved_schemas/<treedb>.upgrade.json. A first projection that 7.23.0-7.25.4 stamped over a file at the literal’s version and did not finish is completed. When the file in use IS the literal, what __system__ misses is restored from it, with one WARNING “Restored from the schema from C: ...” naming the ids; when that open installs a newer literal, what __system__ misses of the old file is no deletion of the operator’s (INFO “What system misses of the schema file in use is no deletion of the operator’s: ...”, with the ids) and the literal is projected. Nothing is reported as the operator’s. After that first open a stamped projection is complete, and a topic the operator deletes stays a draft. A topic or column that 7.25.4 kept after a literal removed it is no draft: the open that removes it reports it in withdrawn_at_open as kind left_by_older_release, with one WARNING “Removed from system what an older release left there: ...”. save-schema leaves such a node out of what it compares and writes, and names its id in data.left_by_older_release (with nothing else changed it answers “nothing to save”); an edit after the upgrade makes it the operator’s, and then it is saved (tests: c_treedb_literal_wins, scenarios FP, OL, OS).

• A delete-treedb cut half way is finished by the next one. Columns first, then topics, then the nodes in no tree, the treedb node last; with the treedb node already gone the nodes left in no tree are still deleted (7.25.4 deleted the treedb node first, and a delete cut after that answered -1 “not projected in system” at every run). It answers 0 with the ids in data.deleted; nothing left also answers 0. The upgrade record is removed too (test: c_treedb_literal_wins, scenario DTK).

• A topic or column that the treedb’s tree no longer reaches (an operator’s unlink, or a projection link that failed) does not block a projection with “Node already exists”: a schema that declares it takes it over, otherwise it is removed (INFO “Node of the treedb that its tree does not reach: removed from system”); when it is operator work its topic is reported unsaved.

• Which treedb a node of __system__ belongs to is read from the node, never from a prefix of its id (a treedb m2 would take the nodes of a treedb m2.b). A column whose topic node is gone and that more than one treedb could own (m2 and m2.b) belongs to the treedb whose record or schema names it, or to the treedb projected now when none does; only that treedb warns, once per node; no node is left for ever. delete-treedb deletes every node of its treedb (a column moved to another of its topics and its nodes in no topic included) and only those: a node of another treedb, or of another topic, linked into it is only unlinked.

• A column the operator moved to another topic, or linked to a second one, is put back where the literal declares it in ONE open. A column linked to a topic that does not declare it is only unlinked when the literal declares it elsewhere or it belongs to another treedb; a topic of another treedb linked here is unlinked (INFO “Topic of another treedb, not declared by the schema from C: unlinked from the treedb in system”).

• A topic whose write or link fails leaves what it holds untouched: the columns of a new topic whose link failed are not written under it, and a take-over or create that fails deletes no orphan node of the declared topic and reports it once.

• A schema whose elements get one qualified id in __system__ (a name with a dot: the column x.y of u and the column y of u.x; the topic b.c of m and the topic c of m.b) is refused with ONE ERROR naming both: the treedb does not open, save-schema does not save it, apply-schema does not apply it. No id changes.

• save-schema refuses a draft with no topics and apply-schema a saved schema with no topics (WARNING, -1, the file in use unchanged): a treedb without topics does not open. saved-schema answers can_apply: false, with the reason, for such a saved schema (7.25.4 answered true and applied it).

• The numbers of a treedb’s node in __system__ (schema_version, c_schema_version) are written last, only when the whole projection succeeded; a new node is created with them at 0 (7.25.4 wrote them first, so a process that died half way left a projection that said it was complete).

• A second open-treedb of an open treedb is refused first (“already open here: close-treedb first, nothing was changed”); 7.25.4 reconciled __system__ first and then failed with “Internal error, tranger client NULL”, and with this release’s whole projection that reconcile would delete topics and withdraw the saved schema. An open that fails before its treedb starts (no valid schema, a collision, no C_NODE) destroys the tranger it created; when the schema is refused, its services stay until close-treedb. When the treedb’s schema is refused (treedb_open_db() fails) the answer is -1 (“did not open, its schema was refused (see the log): close-treedb it before opening it again”); 7.25.4 answered 0 “Treedb opened!”. Until close-treedb, a second open of it answers -1 (“did not open at its last open-treedb...”) and its treedbs row says opened: false. delete-treedb of it answers that it did not open and to close-treedb it first (7.25.4: “while it is OPEN”). C_NODE gives a treedb that treedb_open_db() refused no callback and does not close it at stop, so the failed open logs only its cause and close-treedb logs nothing (7.25.4 logged “TreeDB not found” at the open and twice at the close, with stacks); a write of with_link_events on it sets no callback either. Every answer of open-treedb, close-treedb and delete-treedb starts with the yuno.

• The agent stops when its treedb does not open. The agent opens its treedb (treedb_yuneta_agent) with its schema imposed and exits 0 on a -1 answer (its log has the answer, syslog “Cannot start agent treedb: ...”); ydaemon does not relaunch an exit 0, so the main agent stays down until started again, and yuneta_agent22 (which opens no treedb) stays up as the way in. 7.25.4 answered 0 when the schema was refused, and the agent ran without its treedb.

• The client store decides. If another process holds the client store’s lock, the treedb opens as a replica and nothing is reconciled (INFO).

• A literal with another content under the file’s schema_version is said at every open (WARNING “Schema from C has the schema_version of the dynamic schema in use but another content: NOT applied, raise its schema_version to publish it”, with the diff), with impose_c_schema too (the default: an imposed tie runs the file, and the WARNING carries "imposed": 1). 7.25.4 compared only when __system__'s c_schema_version was another number, and never when imposing: a column added to the literal without raising schema_version, the classic mistake, reached nothing and nothing was said (scenarios SV, SVI). A seed of __system__ at an imposed tie is made from the file that runs, so the literal’s difference is not read as the operator’s draft.

• The saved schema is written whole, through <treedb>.treedb_schema.json.new, an fsync and a rename: a save that died or found the disk full left a torn file where the pending save had been (7.25.4 too; scenario SW).

• save-schema / saved-schema with no treedb_name released a gbuffer carried in the command kw once per treedb (“BAD gbuf_decref()”, and the caller’s buffer freed; 7.25.4 too). Each treedb gets a copy of the kw with its own reference (scenario GB).

• EV_OPEN_TREEDB / EV_CLOSE_TREEDB are public events that nothing implements: they did nothing in silence (7.25.4 too). Each logs an ERROR (“EV_OPEN_TREEDB is not implemented: nothing opened, use the command open-treedb”, and the same for close) and answers -1; use the commands (scenario EV).

• A command that writes through a STOPPED tranger is refused. While the __system__ tranger is stopped (between a stop of C_TREEDB and its next start), save-schema and delete-treedb; while a treedb’s own tranger is stopped, create-topic and delete-topic of it -- all with “<role^name>: treedb ‘<db>’ is STOPPED: its tranger holds no lock until its service starts again” -- and apply-schema of it (“<role^name>: treedb ‘<db>’ is READ-ONLY, this yuno is not the master of its tranger, or the tranger is stopped”). 7.25.4 read the master that the stopped tranger still said: save-schema read nothing and answered “nothing to save”, and delete-treedb went on to delete nodes of __system__.

• apply-schema records what it put in use in a new file, saved_schemas/<treedb>.applied.json: {"schema_version": N, "topics": {"<topic>": "applied"|"in_use"}}, with the record it replaced in previous. It lives as long as its file is in use. It is written before the rename; apply-schema refuses when it cannot write it, and restores the previous record when the rename fails.

• A seed from the schema file stamps c_schema_version with the literal’s version only when the file IS the literal, 0 otherwise. A seed, or the completion of an unfinished projection, reads a file whose topics are a list or a dict keyed by name (what a node opened with impose_c_schema off wrote before 7.25.0; scenario DF).

• A saved draft that is reverted is withdrawn by the next save-schema (withdrawn in the answer). A saved schema lives only as long as the file it was saved against: applied, withdrawn or superseded files are removed; saved now means “waiting to be applied”, stale marks an old file, broken an unreadable one (left out of an apply of every treedb).

• schema_version in __system__ never goes down; apply-schema writes no derived fkey marks into the file in use; a reorder of topics or of columns is a difference (only when the names both sides declare change order; the saved-schema diff carries a __topics_order__ row and a __cols_order__ row per topic). A stored order that says nothing about the node’s place -- absent, or the default 9999 that a node of a projection written before 7.14.0 (every one keyed by rowid, and the qualified ones of 7.13.2) loads with -- is no difference (diff-schema included): such a projection would otherwise read as a draft of every topic. A projection that rewrites the node writes its position, and a reorder the operator makes is still a draft (scenario LQ); a save places such a node as the next bullet says. The INFO “TreeDB schema from C is behind the schema in use, not applied” is logged only when the literal is behind the FILE in use (7.25.4 also logged it for a literal equal to the file while a save was pending, and on an imposed open of a literal behind __system__); an imposed literal behind __system__ logs “TreeDB schema from C is imposed, but it is behind system: the projection is kept”.

• A save keeps the order of the schema file in use. A node whose order says nothing about its place (the default 9999 of every projection written before 7.14.0, or of a column made by hand) was sorted as if 9999 were a position (7.25.4 too): such nodes tied and kept the order the store loaded them in, alphabetical by id, so a save published a reorder of every such topic and column that nobody made, and apply-schema put it in the file. Such a node now goes where the schema file in use declares it, then where the literal declares it, then last (scenario LQ).

• A save writes the places too. A reorder is now a difference (above), so save-schema writes into __system__ the position each topic and column has in the saved schema, where it differs. A column added with an order that is not its position (e.g. 99) therefore does not read as unsaved after its save, nor as a draft after the apply. Each topic and column is found by name, as the diff finds it, and written under its own id: a column the operator moved to another topic keeps its old id, and a topic of another treedb linked here keeps its treedb’s. The topic_version a save writes is found the same way (7.25.4 wrote it under the id composed from the names, which missed such a topic). A name of the saved schema that __system__ does not hold is an ERROR (“Topic of a saved schema not found in system, its place is not written”, and the same for a column and for the topic_version): the schema is built from that same tree (scenarios OP, OM). The same save publishes every topic whose saved place is not the file’s: a node placed in front of its siblings shifts them (with order 5 written on users, the draft is departments, users), and the save publishes users and departments, each with an order row in changes (scenario OX). saved-schema says it before the save: its draft_changed is {"users": true, "departments": true}, so the schema editor’s draft marks and Save/Apply agree with what the save publishes. A node that hangs from more than one parent (the meta-schema’s fkeys are lists: a column linked to a second topic, a topic of another treedb linked in and still in its own) gets no place of its own, since one order cannot say a place in each parent. The save writes its order as 9999 (says nothing) and names it in data.places_not_written. The draft places it by the file in use, then the schema from C, then last, and the diff does not compare its order. So a node that STOPS being shared (unlinked from one parent: the second step of moving a topic from one treedb to another) goes where the file of the parent that remains put it, and that parent, edited by nobody, reads no draft (scenarios SC, ST).

• Two topics with one name in one treedb are refused (7.25.4 too). A topic of another treedb linked in under a name the treedb has made two topics of one name; the schema is keyed by name, so the rebuild kept the last and the diff found the first, and a save published the other treedb’s topic, at a topic_version it did not raise, with no word. treedb_link_nodes() refuses that link (“Treedb already has a topic with this name”, with id and sibling_id), as it already refused two columns of one name in a topic; it still takes the child that is already linked there, and one keyed <parent id>.<name> (the move of a rowid-keyed projection). What the link does not see (an autolink update, an older store) is refused by save-schema, a dry run included, and by the rebuild of the draft: ONE ERROR naming both ids (“Schema refused: two topics of the treedb in system have the same name, unlink or rename one of them”, and the same for two columns of a topic), and -1 with data.twins {what, treedb_name, topic_name, name, first, second} (scenario DT).

• A failed open-treedb keeps the saved schema. An open that installs a newer literal withdraws the pending saved schema (withdrawn_at_open, above) only when the treedb OPENS, so a literal that is refused does not take the operator’s save with it. The open that does not open keeps the file, with an INFO (“Saved schema kept: the open that installs the schema from C did not open; the next one that installs a schema from C and opens withdraws it”), and withdrawn_at_open.saved_schema_version is 0. While the refused literal is the file in use the kept save reads stale (treedb_open_db() writes the literal over the file before it checks the rest); with the good file back and the literal rolled back, it is pending again (scenario KS).

• A save publishes a topic past what runs. A store can run a topic at a topic_version above the one of its schema file (a file written whole over a topic that an apply had raised, by an older release or by a newer literal installed whole). save-schema gave the topic the file’s version plus one, which was not above what ran, so the apply reached nothing and nothing said so (7.25.4 too). It now raises the topic past the higher of the two, and every open that runs such a file says it, per topic (WARNING “Schema file in use declares other columns than the store runs, at a topic_version behind the store’s ...”, with topic_version, running_version and path, the directory whose topic_cols.json says what runs). __system__ holds the file’s columns, so a save with no edit has nothing to save: its answer names such a topic in the comment and in data.store_ahead, which both “nothing to save” answers of save-schema carry ({} when there is none), for example "store_ahead": {"users": {"topic_version": 1, "running_version": 2, "path": "..."}}. To keep what runs, edit the topic in __system__ to those columns, then save-schema and apply-schema. To run the file’s, raise its topic_version above running_version, and the schema_version, in the schema from C (scenario BH).

Event loop (yev_loop)¶

• A full submission queue ended the process in 7.25.4: of the 12 places that ask io_uring_get_sqe() for an entry, 10 used the NULL entry (a crash) and 2 logged “io_uring_get_sqe() FAILED” and aborted. The queue is flushed and the entry asked again; when the kernel still takes nothing (on an older kernel a CQ overflow answers EBUSY until the completions are reaped), the submission is KEPT and made at the next cycle of the loop, in order (a timer is armed, a stop reaches its event). A stop of a submission still kept reaches the callback as a cancel (STOPPED, -ECANCELED). One WARNING when the loop starts keeping: “Submission queue full and the kernel takes nothing: kept for the next cycle”. Only a submission that there is no memory to keep fails: CRITICAL “No memory to keep a submission”, then the caller answers -1 with its ERROR “No memory to keep a submission: <what did not happen>” (every event start -- connect, accept, write, read, sendmsg, recvmsg, poll -- “...: event NOT started”; a timer “...: timer NOT started”; a cancel “...: event NOT canceled”; a re-arm inside the loop “...: accept event NOT re-armed” / “...: periodic timer NOT re-armed”, with no caller to answer; a loop stop “...: loop NOT stopped”). Test yev_events/test_yevent_sq_full; the hot path does not move (perf_yev_ping_pong -1.1%, perf_tcp_test4 +1.6%, perf_tcp_test5 -0.8%: within noise; figures in performance/c/README.md).

• A submission the kernel did not take is no longer left waiting: a failed io_uring_submit() can leave its entry in the queue (the submit that hands over the kept entries included); the loop submits those entries again at each cycle, with a 10 ms retry wait. One WARNING when it starts (“Submissions the kernel did not take: submitted again at each cycle”), an ERROR after 100 cycles (“Submissions not taken by the kernel for many cycles of the loop: their operations wait”), and an INFO (“Submissions taken by the kernel again”) when the kernel takes them again after that ERROR.

• A stop of an event whose submission is still in the queue takes it back, as for a kept one: the entry is found by its event (never by its fd) and becomes a NOP whose completion is not delivered; the callback gets STOPPED, -ECANCELED. Otherwise the stale operation ran later on the fd the stop had closed, and a new timer that got the same fd number never fired. The loop does not block on the ring while it holds the completion of such a take-back, also when a posted action (gobj_post_event()) made the stop: the STOPPED comes at the next cycle, not with an unrelated completion (test yev_events/test_yevent_kept_after_post). A stop that has no entry for its cancel and no memory to keep it answers -1 and gives up nothing: the event keeps its gbuffer and the fd of a timer or connect, and a read then completes with its data (test yev_events/test_yevent_stop_nomem).

• A closed fd takes back the submissions of other events on it. A write still in the submission queue after a failed io_uring_submit() went to the kernel at the next submit that worked (7.25.4 too), and so did a kept submission: when the event that owns the fd (a connect, an accept, a timer) was stopped or destroyed and the fd closed, the operation ran on whatever file reused the number -- the bytes of the old connection went to the new one. Before the close(), the loop now takes back every submission of another event on that fd that the kernel has not taken, in the kept list and in the queue, and that event completes as STOPPED, -ECANCELED, at the next cycle, with a WARNING (“An fd is closed with submissions of other events on it that the kernel did not take: taken back, completed as canceled”); with no memory for that completion they are dropped all the same, with an ERROR (“...: dropped, the event will not complete”). An entry of the queue is told by the event that owns it: every entry the loop hands out has its fd and its owner cleared first, so what an earlier operation left in the same ring slot is never taken for a submission on the fd, and the stop of a running timer or connect prepares its cancel before its fd is closed. Tests yev_events/test_yevent_close_fd_kept, yev_events/test_yevent_stop_stale_sqe.

• A zero-copy UDP send (io_uring_prep_sendmsg_zc()) gives two completions, the result (IORING_CQE_F_MORE) and a notification (IORING_CQE_F_NOTIF); the loop counted one, so an event destroyed at the first completion -- as C_UDP_S does when all the data is sent -- was read after it was freed by the notification (7.25.4 too). The callback is called once, at the first completion; the notification only ends the operation. A kernel without zero-copy sendmsg (probed at yev_loop_create()) gets a plain sendmsg.

• An IPv6 peer is kept with its real length, so C_UDP_S answers it and an accept or connect takes it: in 7.25.4 the address was a 16-byte struct sockaddr, an IPv6 accept or connect was refused, a received IPv6 peer was cut and the reply refused (-EINVAL). A url can hold an IPv6 literal in brackets (udp://[::1]:5000).

• A stop keeps the gbuffer of an operation the kernel still has, and releases it at the LAST completion of the operation, which is not always before the callback (a zero-copy send’s notification comes after it); the callback of a stop sees the event STOPPED, without a gbuffer. 7.25.4 released it at once while the kernel could still write into it or read it. A stop does not reach the callback of an IDLE event that is not a timer, of an IDLE zero-copy send whose notification is pending, of a stop without memory, or of a RUNNING event destroyed while the loop stops; a stop never closes an accept socket. yev_set_gbuffer() refuses to replace the gbuffer of such an operation.

• yev_loop_destroy() frees the destroyed events whose completions have not come: it cancels what the kernel still has, collects the completions for up to 1 s, and frees the rest with an ERROR (“Loop destroyed with events whose completions did not come: freed”, with cancel_submitted); in 7.25.4 they leaked, or were freed while the kernel still had their operation. A zero-copy send whose notification has not come is waited for up to 5 s in all, and then NOT freed, with a WARNING (“Loop destroyed with zero-copy sends whose notification did not come: NOT freed, the kernel may still read their gbuffer”): the kernel may still read its gbuffer. Test yev_events/test_yevent_loop_end_drain (case E). When there is no entry for that cancel, an ERROR says so first (“Submission queue full: the cancel of the events left is NOT submitted, their completions may not come”).

• A connect binds its src_url, and a bad one is an error: in 7.25.4 a non-empty src_url was never parsed -- a dynamic build failed the connect with “getaddrinfo() src_url FAILED”, and a static one bound the socket to the loopback address with a port the kernel picked, whatever the src_url said. It can be "host:port", "[ipv6]:port" or "schema://host:port", resolved in the family of each address of the destination: an address in whose family the src_url has none is skipped and the next one is tried; a bad src_url, a failed resolution or a failed bind is logged, naming the src_url, and the connect gets no socket. That error path no longer leaks the destination addresses. Test yev_events/test_yevent_connect_src_url.

Transports and inter-yuno events (C_TCP_S, C_UDP_S, C_IEVENT_*)¶

• C_UDP_S sent only the FIRST datagram of its queue (7.25.4 too): the send completion asked for ST_CONNECTED, a state C_UDP_S does not have, and every later datagram waited for ever. And a send that did not start (a gbuffer with no peer address or a bad address length, or no memory to keep the submission) leaked its event and gbuffer (7.25.4 too), left tx_in_progress above 0 (a stop waited for ever) and held the queue. Such a datagram is dropped with an ERROR (“Cannot send datagram: dropped”) and the next one is sent. Test c_udp_s_tx.

• A datagram the kernel refuses no longer stops C_UDP_S (port 0, another family, a broadcast without set_broadcast, too big). It is dropped with a WARNING that names the peer and the cause (“UDP: datagram refused by the kernel, dropped”, with errno and strerror) and the next one is sent; a send of 0 bytes does not stop the server either. In 7.25.4 it stopped the whole server, reading too, and only a trace said so. Only a read that fails while the server runs stops it now, with an ERROR (“UDP: read FAILED, the server stops listening”), and so does a read that cannot be started again after a datagram (“UDP: the read cannot be started again, the server stops listening”; 7.25.4 ignored that failure, and the server stayed up and deaf with nothing logged). Such a stop ends in ST_STOPPED and publishes EV_STOPPED, also with a datagram in flight. Tests c_udp_s_tx, c_udp_s_self_stop.

• C_UDP_S refuses a udps:// url (7.25.4 too): there is no DTLS. In 7.25.4 the server listened with no TLS session, and the first datagram crashed the yuno. The start fails with an ERROR (“A secure url (udps://) is not supported by C_UDP_S: there is no DTLS”), and with exitOnError (the default) the yuno exits with 0. use_ssl is always false, so reload-certs and view-cert answer “Listener is not TLS-enabled or not running”. See “Upgrade steps”. Test c_udp_s_self_stop.

• A stop and a start of C_UDP_S (the logcenter’s pause-yuno / play-yuno) start a new read on the new socket. In 7.25.4 the old read restarted on the number of the closed socket, which could be any file of the process, and reception ended with no log. A stop drops the datagram in flight and the queue (WARNING “UDP server stopped: the datagrams waiting to be sent are dropped”, with the count), and a send that completes after a restart does not move the new queue: in 7.25.4 the datagram in flight at the stop held every later one. Test c_udp_s_restart.

• The EV_RX_DATA gbuffer of C_UDP_S always carries the peer as its label. In 7.25.4 the label was set only when tracing, so C_GSS_UDP_S (the logcenter) put every peer on one channel and joined the pieces of long log lines from different yunos into corrupt records. C_GSS_UDP_S keeps a channel per peer (a source ip:port), and caps what the peers make it hold: a frame buffer starts at 4 KB and doubles up to max_frame_size (default 1 MB, the old fixed size); a frame with no end within it is delivered cut, with a WARNING at most each 10 s (“Frame without end within max_frame_size, delivered cut”); max_channels (default 1024) drops the datagrams of new peers beyond it (WARNING “Too many peers, datagrams of new peers dropped”, on the transition); max_pending_bytes (default 8 MB, all peers together) drops a datagram beyond it with its peer’s unfinished frame (WARNING “Too many bytes in unfinished frames, datagram dropped with the unfinished frame of its peer”, at most each 10 s, with a count); a channel that cannot be allocated is logged, never dereferenced. A frame that C_GSS_UDP_S publishes carries its peer’s label and address, so a host can answer it: EV_SEND_MESSAGE sends a gbuffer that has an address to that address, one without an address to the known peer its label names, and refuses a gbuffer with neither (ERROR “EV_SEND_MESSAGE without a peer: no address, and its label names no known peer; dropped”, -1). In 7.25.4 a send by address logged “UDP channel NOT FOUND”, a send by label had no address to go to, and a frame could not be answered. Test c_udp_s_rx (case 4: one-byte datagrams from many ports; case 5: answers by label and by address, and a send with neither).

• C_UDP_S publishes EV_STOPPED when a stop completes. Its event table declared the STATE name ST_STOPPED as an output event, and nothing was published (7.25.4 too). EV_TX_READY is declared and never published (transport.md says so).

• An answer written in the EV_RX_DATA gbuffer of C_UDP_S goes back to its sender, whole (7.25.4 too). transport.md says a host can answer a datagram by sending the received gbuffer back as EV_TX_DATA, but C_UDP_S cleared that gbuffer after the publish and read the next datagram into it: an answer that waited in the queue was sent empty (“Cannot start event: gbuffer WITHOUT data to write”, “Cannot send datagram: dropped”) or with the bytes and the peer of the next datagram, the same gbuffer could sit twice in the queue (“Wrong dl_item_t, WITH links”, memory not freed), and a zero-copy send could read memory the next read was writing. When the host keeps the gbuffer, the next read now takes a new one of rx_buffer_size; when nobody kept it, it is cleared and reused as before (one refcount test on the common path). No memory for that new gbuffer stops the server, with an ERROR (“UDP: no memory for the next read, the server stops listening”). Test c_udp_s_echo.

• C_TCP_S asks denied_ips at accept, and C_UDP_S asks both ip lists for every datagram; each counts every refusal in a new stat (refusedConnxs, rxRefusedMsgs) and says it at the first refusal of each cause and then at most once a minute (see “Security”). Tests c_tcp_s_ip_lists, c_udp_s_rx.

• C_TCP: a write that does not start drops the connection (7.25.4 too). A write whose event could not be created or started (no memory to keep its submission, an empty gbuffer) was ignored: the event and its gbuffer leaked, tx_in_progress stayed above 0, the later writes waited for ever, and a stop waited in ST_WAIT_STOPPED for ever. The connection is now dropped, with an ERROR (“Cannot start a write: the connection is dropped” / “Cannot create a write: the connection is dropped”): a TCP stream cannot go on with a piece missing (C_UDP_S drops one datagram and sends the next). Test c_tcp/test5.

• C_TCP: the stop of a client already disconnected publishes EV_STOPPED (7.25.4 too). A client stopped while it waited for its reconnect timer (after a failed connect) went to ST_STOPPED, published nothing and kept its connect event, so the next gobj_start() failed with “yev_connect ALREADY exists” and the client never connected again. That stop now frees the connect event and publishes EV_STOPPED once, inside gobj_stop(), like every other stop of C_TCP: a host that sets its flags after gobj_stop() gets the event before they are set. transport.md, “The stop”. Test c_tcp/test6.

• A C client can withdraw a subscription that carries a __global__ (7.25.4 too). C_IEVENT_SRV compared the withdrawal with the stored __global__, which also holds the gate’s back-metadata that the peer never repeats: nothing matched, and the subscription stayed until the channel closed. The withdrawal is filtered as the subscription is, and its __global__ is compared with the stored one without the gate’s _ keys. Test test_c_ievent_srv_peer_subs.

• A repeated hard subscription is one (7.25.4 too). gobj_subscribe_event() stores a subscription’s __config__ without __hard_subscription__, so a second hard subscription with the same kw matched nothing: it was made again, with no log, and each event arrived twice; a hard subscription over a plain one did not replace it either. __hard_subscription__ is no longer compared: a subscription that matches a hard one returns the hard one, with a WARNING (“Hard subscription REPEATED, the one there is kept and returned”), and a hard one over a plain one replaces it. A repeated plain subscription is still replaced (“subscription(s) REPEATED, will be deleted and override”). Both WARNINGs are about the caller’s subscription, not a broken invariant: they carry no stack now, and their kw is capped to 256 bytes (7.25.4 dumped the whole kw, with a stack). A repeated __own_event__ or __rename_event_name__ subscription is compared as it is stored, so it replaces the one there, and gobj_unsubscribe_event() with the same kw removes it: 7.25.4 made a second one (each event delivered twice) and could not withdraw it. Test c_subscriptions/test3.

• C_IEVENT_CLI sends nothing to a stopping transport. A subscription added or withdrawn while the client is stopping (after gobj_stop(), before the close arrives) sent its frame down to the transport that was closing, and C_WEBSOCKET or C_TCP logged “Event NOT DEFINED in state” (7.25.4 too). Nothing is lost: the peer drops the channel’s subscriptions when it closes, and an added one is sent at the next open.

• C_IEVENT_SRV stops its protocol gobj (C_WEBSOCKET / C_PROT_TCP4H) when it is stopped, as every other layer stops the one below it. In 7.25.4 a gate stopped with a plain gobj_stop() -- the way the yuno stops an autostart service -- left them running, and the yuno exited with “Destroying a RUNNING gobj” (the agent escaped it because it calls gobj_stop_tree()). The protocol gobj still lives as long as the gate, not as long as one connection, and C_IEVENT_SRV starts it again when it starts: disable-channel / enable-channel bring a channel back whole, because C_CHANNEL’s mt_enable now starts its tree (gobj_start_tree(), what its comment and gobj_enable()'s default always said). C_WEBSOCKET and C_PROT_TCP4H stop their transport only when it runs (no “GObj NOT RUNNING”). Test c_subscription_authz (every channel disabled and enabled again, then a session opens on each).

• An unsubscribe that matches nothing is said for what it is. C_IEVENT_SRV counts the subscriptions of its channel that the authz refused: the INFO “UNSUBSCRIBING event never subscribed, its subscription was refused” is logged only for one of them, and any other unsubscribe that matches nothing is a WARNING without a stack (“UNSUBSCRIBING event matches no subscription of this channel”), where 7.25.4 logged the ERROR “No subscription found” with a stack. gobj_unsubscribe_event() warns when a hard subscription it matched is left in place (“Hard subscription not removed, only gobj_unsubscribe_list() with force removes it”); 7.25.4 counted it as removed and said nothing.

• C_PROT_MQTT2: an incoming QoS 2 message queued at the reload of a persistent session is released (7.25.4 too). The move of queued incoming messages into flight tested the quota the wrong way round (it stopped when nothing was in flight and moved a message when the quota was full; mosquitto stops when the quota is spent), gave the moved message a NEW packet id and sent its PUBREC with it: the client’s PUBREL for its own id found nothing (“Message not found”), and the message was never released. A queued message now goes in flight when a slot frees, with its own id, as in mosquitto. Only a session reloaded with more pending QoS 2 messages than max_inflight_messages (the limit lowered between two connections) has queued ones. Test c_mqtt/queued_in (a raw client).

• C_PROT_MQTT2 client: a QoS 2 message received again with DUP=1 is found by its packet id (7.25.4 too). It was looked up by queue rowid: the old copy stayed in flight for ever, the next message with the same packet id delivered the stale copy again, and an unrelated message could be removed instead. Now the copy waiting for its PUBREL is found by packet id, in flight or queued, as in mosquitto, and replaced (WARNING “QoS 2 message received again (dup): it replaces the copy waiting for its PUBREL”, was “removing an inflight qos2 dup message”). And a client’s QoS 2 PUBREL no longer logs “QoS mismatch”: the qos flag bits (32) were compared with the qos level (2). Test c_mqtt/client_queues.

• MQTT queues: a message that expires before it is sent gives its slot to the queued ones (7.25.4 too). The send loop dropped the expired message and left the queued messages waiting, although a slot was free: with 20 in flight and the 21st expired, the 22nd was never sent. The release now moves queued messages in flight while there is room, sends, and repeats while an expiry frees a slot. Test c_mqtt/client_queues.

• A queued MQTT message moves in flight with its content (7.25.4 too). tr2q_move_from_queued_to_inflight() moved the message first and read its content after: a read that failed left an incoming QoS 2 message in flight with no content, and no PUBREC was sent. The content is read first; on a failure the message stays queued (ERROR “Cannot load the content of a queued message: it stays queued”) and the call answers -1. And tr2q_check_backup() does not back up while messages are queued (it answers 0): the backup could lose their content. Test tr_queue/test_tr2q_queued.

• MQTT: the broker keeps the client’s Receive Maximum (7.25.4 too). With max_inflight_messages 0 (no limit of the broker’s own), the broker sent every queued QoS 1 and QoS 2 message at once, over the Receive Maximum of an MQTT 5 client. The out window is now the queue’s limit, the lower of the two maximums, as in mosquitto. Test c_mqtt/out_flight (a raw MQTT 5 client with Receive Maximum 2: two messages, then two more after the acks).

• MQTT broker: list-queues qos= keeps the pending filter (7.25.4 too). A qos= replaced the default pending=1 and listed the messages already delivered. The conditions combine now: list-queues qos=1 lists the pending QoS 1 messages, and list-queues pending=0 qos=1 the delivered ones. Test c_mqtt/out_flight.

• MQTT: an ack of the wrong packet is a protocol error (7.25.4 too). A PUBACK for a QoS 2 message, a PUBCOMP for a QoS 1 message or before the PUBREC, and in the client a PUBREL of the wrong QoS, were an ERROR, and the message was removed as delivered. Now it is a WARNING (“QoS mismatch”, MSGSET_MQTT, with client_id and peername), the connection is closed (an MQTT 5 peer gets DISCONNECT 0x82 first) and the message stays in flight, as in mosquitto. An ack of a packet id that is not in flight is a WARNING (“Message not found in trq_out_msgs”, was an ERROR): the id comes from the peer. See “Upgrade steps”. Test c_mqtt/out_flight.

Agent, gobj-c and tools¶

• The agent removes old audit files. New attribute audit_keep_days (default 7; 0 keeps all, as 7.25.4 did) is the retention of /yuneta/realms/agent/agent/audit/. At start and at each new audit file the agent removes the audit files older than that (only names with the shape of the audit mask, never a link) and logs one INFO “Old audit files removed” with the names. Up to 7.25.4 nothing was removed (19 GB on wattyzer). An existing large directory is swept at the first start: to keep more, set agent.audit_keep_days in yuneta_agent.json before that start. New rotatory_remove_old_files(); the sweep at a new audit file runs inside the write of its first record (once a day, or at a size rotation).

• The agent’s audit record is small, and holds no secret and no keystroke. A read-only command (list-*, view-*, get-*, info-*, dir-*, help, stats, services, nodes, treedb-info, topics, ...; the list is in DEBUGGING.md 5.5) is written as {command, date, user} only. A command with a __reset__ value (stats-yuno stats=__reset__) is a write. The command word is read as the parser reads it (any case, quotes, aliases, looked up in the agent’s command table): WRITE-TTY, 'write-tty', EV_WRITE_TTY are console writes too, and CLOSE-CONSOLE ends the bursts. command-yuno / command-agent are judged by the command they carry, the one its handler reads: the key exactly command (the parser stores a key as typed), so command-yuno id=gate COMMAND=list-yunos with a kw command=delete-yuno runs delete-yuno and gets the full record; a command key in any other case is never read-only, and write-tty NAME=x does not move the record to another console. Any other command is written as {command, date, user, source, kw}: __md_iev__ is no longer written, and source keeps the console purpose and each inter-yuno hop (role, yuno, service, user, host). user, each field of a hop, console_purpose and the console name of a console write come from the peer: each is redacted like any other string, and one longer than 1024 bytes is written as <N bytes, not scanned, sha256:HEX>. A content64 is never written (blanks around the = included): it becomes <N bytes sha256:HEX> of the decoded content (the sha256sum of the binary). A secret is never written: the value of a parameter named like password, pwd, secret, token, jwt, private_key, api_key (set with write-attr attribute=api_key value=... on wattyzer’s gate_pvpc), apikey, x-api-key, cookie, session_key, __session_id__, auth_data, passphrase, credential, authorization, bearer or salt (and the value of a write-attr of such an attribute, also as {attribute, value} in a json object of the kw) is <redacted>, in the kw at any depth and in any string, as are the token after Bearer , the credentials after Basic (the base64 of user:password) and anything shaped like a JWT (also one followed by a .). The value of a secret name=value is its whole shell word, quoted pieces and escapes included: password=\"two words\", password="a\" S", password='it'\''s S'; the closing quote of a "..." value that ends with the secret stays in the record (command="write-attr attribute=api_key value=S" n=1 is written value=<redacted>" n=1). A name is judged with its json escapes decoded, at any level: a key (\"secret key\":, \"password/db\":, a key or an attribute written api\u005fkey), and a write-attr given as JSON text inside a string of the kw is recognized: {"x":"{\"attribute\":\"api_key\",\"value\":\"S\"}"} writes no S. A json key is read with its escapes, and a JSON text given inside a JSON text (quotes escaped as \" or \u0022, up to 8 levels) is scanned with its escapes decoded, the record keeping the same JSON text (deeper than 8 levels the run is written as <N bytes, not scanned, sha256:HEX>), whatever quotes come before it (a double-quoted parameter, a stray quote). When no quoted run holds it whole (x="{\"password\":...}", where the parser’s value ends at the first \", or '{\"password\":...}'), the key is read by its shape and its value is taken with the quotes of its level. The redaction is stricter than the parser: attribute / value match in any case, and a write-tty or a secret carried under COMMAND= is hidden too. Up to 7.25.4 check-user-pwd and set-user-pwd wrote the password in clear text (see “Security”). The record is built before the command parser and the authz, from the text of any peer that can send a command: its scan is one pass in linear time at each level of escaped JSON text (at most 8), and it scans at most 128 MB of strings per record, all levels together (a string past that budget is written as <N bytes, not scanned, sha256:HEX>; of the command text, its first word comes first). A console keystroke (write-tty) keeps only who, when, which console, and how many writes and bytes: one record at the first write of a burst (one user, one console, up to 60 s) and one for the rest when the burst ends; up to 7.25.4 each keystroke wrote the whole kw with the keystroke in base64 (1000 keystrokes: 922 KB, now 945 bytes). A field of a __md_iev__ hop from a peer that is not a string is written as "", with one WARNING (“Audit: bad md_iev from a peer, written as empty”). An install-binary of a 32 MB yuno went from 134 MB to 541 bytes (wattyzer wrote 0.6-1.2 GB of audit on a deploy day). A day of audit that crosses max_megas_audit_file continues in .OLD.1, .OLD.2, ...: up to 7.25.4 each size rotation removed the previous .OLD, so a day that crossed the limit twice lost its first part (wattyzer lost the mornings of 22 and 23 September 2026). New rotatory_keep_all_old_files() (off by default: the yuno logs keep their one .OLD).

• The agent flushes every audit record before the command runs (one write() per command, about 0.75 us more: perf_rotatory audit_record_flush 1.34 us against audit_record 0.60 us, the same 12 alternated rounds): up to 7.25.4 a record could wait in the buffer of the file and be lost in a crash.

• A command whose kw carries a gbuffer releases it once. The command parser gives the handler a new kw with the keys of the caller’s kw, and it copied them with json_object_update_missing() (every command, with or without a parameter schema); the default stats parser (build_stats()) handed the kw on with json_incref(). Neither took a reference of the gbuffer, and each KW_DECREF released it: “BAD gbuf_decref()”, or a gbuffer freed while its owner still held it. The parser uses the new kw_update_missing(), which takes that reference, and so does the EV_ON_CLOSE of C_IEVENT_SRV; build_stats() and C_MQIOGATE’s view-channels use kw_incref(). C_NODE create-node / update-node had worked around it (they took a second reference of the bytes of the file columns); they take the command kw’s own now. Test command_binary_kw.

• kw_set_dict_value() overwrites, as its header always said, and answers -1, logged, when it writes nothing (a scalar or a null in the middle of the path, “long path”; an index outside its list; an empty path, “path empty”). Up to 7.25.4 a key that already existed kept its old value, with no sign: a peer’s own __username__ survived the gate (see “Security”), a stale ref in a string fkey column could never be removed (see “Data loss and integrity”), and gobj_set_stat() / gobj_incr_stat() / gobj_decr_stat() never changed a stat that existed. All 38 callers in the tree were checked: none relied on “set only if absent”, and none reads the return. gobj-js’s kw_set_dict_value() already overwrote. Test kw/test_kw_set_dict_value.

• New kw_twin(gobj, kw): a new kw with its own top level, the values shared, and each binary field (gbuffer) increfed as kw_incref() does, so the twin and the original each release their own reference. It is what gobj_publish_event() gives a subscription that rewrites the kw (see “Security”), for a kw written at the top level only: json_t *mine = kw_twin(gobj, kw);, then json_object_set_new(mine, "x", json_integer(1)); leaves kw as it was, and KW_DECREF(mine) releases the twin (kwid.md).

• A log call leaves errno as it found it (gobj_log_*(), the traces), and a failed mkrdir() leaves the cause in errno (ENOTDIR when a part of the path is not a directory, ENAMETOOLONG, EINVAL for an empty path, or the syscall’s); rmrdir() / rmrcontentdir() set ENAMETOOLONG / EINVAL on their refusals. A caller that logged strerror(errno) after a helper that logged its own failure named another cause, or “Success” (7.25.4 too): tranger2_create_topic()'s CRITICAL “Cannot create TimeRanger subdir. mkrdir() FAILED” always said errno 0, and callers in timeranger2, C_TREEDB and the agent had the same defect. Tests tr_queue/test_tr_queue_backup_failed, helpers/test_dir_read_error.

• gbuffer_base64_to_binary() decodes base64_len chars instead of reading up to a '\0': a slice of a longer text (a content64='...' inside a command line) failed to decode.

• gbmem_realloc() refused because the new size is larger than the largest block leaves the old block valid and tracked: with CONFIG_DEBUG_TRACK_MEMORY 7.25.4 took the block out of the tracking first, and the later free logged “Wrong dl_item_t, WITHOUT links” and wrapped the memory counter. The kept lists of yev_loop reach this path.

• rmrdir() and rmrcontentdir() no longer follow symbolic links: a link to a directory inside the tree was walked into and the files of its TARGET were deleted (outside the tree); a dangling link made the removal fail. A link is removed as a link; their failures name the path, and rmrcontentdir() no longer fails silently. An entry that another process removes during the walk is not an error (it returned -1 with no log). mkrdir() over a path that exists and is not a directory logs “Not a directory: the path exists and is not a directory” (ENOTDIR) and returns -1; over a dangling link it logs “newdir() FAILED” (EEXIST) and returns -1. 7.25.4 returned 0, with no log and no directory (its check could never be true).

• rmrdir() / rmrcontentdir() refuse, with a log, a tree whose paths do not fit in PATH_MAX or that is deeper than 1024 levels (they could recurse without end); mkrdir() refuses, with a log, a path of PATH_MAX or more (7.25.4 cut it silently and returned 0).

• find_files_with_suffix_array() never lists a symbolic link (on filesystems without d_type it used stat() and listed a link to a file).

• A directory walk whose paths do not fit in PATH_MAX fails, logged (7.25.4 too). walk_dir_tree(), walk_dir_array() and get_ordered_filename_array() ignored a failed build_path(): the entry’s path was the directory itself, and the walk went into it again until the process crashed (SIGSEGV), or answered 0 with the directory given to the callback as its own entry. find_files_with_suffix_array() on a filesystem without d_type stat’ed the directory instead of the file and dropped the file with no log. The walk now answers -1 with the ERROR “Path too long, the directory cannot be walked”, and a tree deeper than 1024 levels (16 on ESP32) with “Tree too deep, the directory cannot be walked”, as rmrdir() does.

• A walk callback that returns FALSE stops the whole walk (7.25.4 too): only the directory of the callback stopped, and the walk went on in the next one, where helpers.h and directory_walk.md said it would stop. walk_dir_tree() still answers 0. The transient causes that now fail a walk are under “Data loss and integrity” (a key directory that cannot be listed). Of the callers, timeranger2, the tr_treedb import and blob sweep, dir_listing and c_resource2 already answered the -1; fs_watcher, C_FS and timeranger2’s rt disk search log it and stop there instead of skipping one subtree. Test helpers/test_dir_read_error.

• The agent’s dir-yuneta, dir-realms, dir-repos, dir-store, dir-logs and dir-local-data answered an EMPTY list with result 0 for a directory that could not be listed (does not exist, mode 0, EMFILE, a bad match): they ignored the return of the listing. They answer -1, “<role^name>: cannot list ‘<dir>’, see the log”, with no data (the cause is in the log): dir-store subdirectory=nope answers “-1: yuneta_agent^agent: cannot list ‘/yuneta/store/nope’, see the log”. Tests helpers/test_dir_listing, helpers/test_dir_array_nomem (the listing helpers themselves are under “Data loss and integrity”).

• save_json_to_file() checks close() -- a failed close is a CRITICAL at on_critical_error -- and logs a missing directory when it may not create it.

• rotatory (the log files): a record is checked once and written whole. Up to 7.25.4 each piece of a record rebuilt the file name (localtime()) and ran access() + fstat(): an agent audit record cost 6.2 us, now 0.55 us. A record is no longer split between two files at a size rotation. A log file RENAMED by another program is no longer noticed (a removed one still is); the free-disk check runs every 100 records instead of every 100 pieces.

• rotatory: a full disk stops only the log file on it, and it writes again when the space is back (checked every 100 records; one line on stdout/syslog when it stops, one when it resumes with the number of dropped records). Up to 7.25.4 one full disk stopped EVERY file log and the agent audit of the process until it was restarted. A handle closed by rotatory_close() / rotatory_end() is never touched again (the logger keeps its handle): a write, flush, truncate or second close through it does nothing; up to 7.25.4 it read freed memory and could close it twice.

• rotatory: a clock set back across midnight empties no log file. Up to 7.25.4 each new file name was opened with "w": a step back at 00:00:05 emptied the file of the day before, and the step forward emptied today’s file with its first records (the agent audit and the yuno logs). Now an existing file is emptied only when it was last written before the day its name is used for (last week’s file of a W mask, as intended); a handle with rotatory_keep_all_old_files() never empties a file.

• rotatory: a new day on a full disk opens the new file and calls the newfile callback (where the audit runs its retention and frees space); a piece of 0 bytes no longer closes the file until the next day; a failed write closes the file and the next record opens it again. An old file of a mask with a day letter or the month and without the year is emptied at the first record after rotatory_open(): up to 7.25.4 a yuno that started on a Monday appended to last Monday’s W file, so one file held 8 days. A mask with the year, and a mask with no date letter (a fixed name, logcenter.log), never empties a file; an MM-only mask is judged by its month (a restart on the 15th does not empty the month’s file). The decision waits for the first record, so rotatory_keep_all_old_files() called right after the open applies to the file the open found.

• rotatory: the newfile callback (rotatory_subscribe2newfile()) runs for a NEW file only (a new name, or a size rotation), never for the same file opened again after a failed write, a removed file or a failed truncate. The logcenter sends a summary e-mail from that callback, and the agent audit runs its retention scan there: a log file that refuses writes (quota, no inodes, EFBIG, EIO), and so is opened again at the next record, sends no e-mail per log line and scans nothing per command. The callback of a new file whose open fails (EMFILE, an inode quota, a directory that refuses writes for a moment) runs once, at the next open that works, with the old name of before the failure; on a full disk that open is tried every 100 records, since the retention the callback runs is what frees the space. In 7.25.4 a failed open of a new day ended the process of a handle opened with exit_on_fail (next bullet) and stopped any other for the rest of the day, and that day’s callback (the audit retention, the logcenter summary) never ran.

• rotatory: exit_on_fail is for rotatory_open() only. A file that cannot be opened later -- a new day with EMFILE, an inode quota, a directory that refuses writes, a removed file, the reopen after a failed write, a truncate -- is printed once on stdout and syslog (“_rotatory(): Cannot open ‘<path>’ file, <err>”), the record is dropped, the next record tries again, and “_rotatory(): ‘<path>’ is open again” is printed when it works; the pending newfile callback then runs. In 7.25.4 the first such failure ended a process whose handle was opened with TRUE: the agent (its audit) and every yuno (its file log). rotatory_open(..., TRUE) still exits when the open itself fails. Test helpers/test_rotatory (each case in a forked child with exit_on_fail).

• rotatory: the size limit is compared in bytes (7.25.4 too). It was compared in whole megabytes, so a limit of 8 MB rotated a file at 9 MB, and a yuno’s logs reached 126 MB instead of 112 MB (7 days x 2 pieces x 8 MB; DEBUGGING.md 5.3). A file of exactly the limit is not rotated; the next record over it is. Test helpers/test_rotatory.

• rotatory: at a new day the file of the day before is not size-rotated. In 7.25.4 a day whose last piece crossed the size limit had that file renamed to .OLD at the first record of the next day, and the day’s earlier .OLD was removed.

• rotatory: with rotatory_keep_all_old_files(), a size rotation whose rename fails (chattr +a, a read-only bind, a MAC denial) keeps the file, appends to it, and tries the rename again after 60 s of the monotonic clock (a wall clock set back or forward does not move it) or at the next name, with one line when it fails (“_rotatory(): Cannot rename ‘<path>’ to ‘<path>.OLD.1’, <err>, the file is kept and grows, the rename is tried again every minute”) and one when it works again (“_rotatory(): the size rotation of ‘<path>’ works again”). Without it, a failed rename still empties the file, as in 7.25.4.

• The entry point closes the log files last: up to 7.25.4 they were closed before the final cleaning and the memory leak report, so “system memory not free” never reached the yuno’s log file.

• yuno-skeleton: the four C templates logged with MSGSET_INTERNAL_ERROR, which the unified msgsets renamed MSGSET_INTERNAL (2026-04): a gclass generated from them did not compile. They use MSGSET_INTERNAL.

• yuno-skeleton: the timer of gclass_service, gclass_child and yuno_citizen reached nobody. They created it with gobj_create(), and C_TIMER subscribes its parent only when it is a pure child: its EV_TIMEOUT was published without subscribers and the template’s ac_timeout never ran. They create it with gobj_create_pure_child(), as yuno_standalone and the kernel gclasses do. The JS template already did.

• New benchmarks performance/c/perf_timeranger2, perf_tr_treedb, perf_c_treedb (see “Performance”) and perf_rotatory (the rotatory figures, with a case that flushes each record): each prints one line of JSON per result, and ctest runs them with small sizes.

• The test harness (capture_log_write(), gobj-c testing.c) no longer counts “io_uring_queue_init_params() pinned-memory pressure, retrying” as an unexpected log: it speaks of the machine (other processes held locked pages when the test created its loop), and the loop retries and goes on. A full suite run beside other work failed test_yevent_listen1 on it; the message is still printed.

• create-yuno refuses a release name too long for it (7.25.4 too). It built yuno_release into 120 bytes and ignored the failure: a binary version plus a configuration version longer than that stored a cut pkey2 and answered success; find-new-yunos never found that name, offered the yuno again at every call, and create=1 failed on it with “Yuno already exists” for ever. The buffer is NAME_MAX, and a name that does not fit answers -1: “<role^name>: Yuno ‘<role>.<name>’: release name too long (‘<binary version>’ + ‘<config version>’)”.

• find-new-yunos says which rows are already registered. On a resumed upgrade (a find-new-yunos create=1 that ran, and no deactivate-snap after it) its preview listed those rows again as new, and create=1 failed on each with “Yuno already exists” (7.25.4 too). A row whose yuno already exists at the new release stays in the preview, marked “already registered, pending promotion (deactivate-snap): create-yuno ...”; create=1 skips it, and the comment gives the count (“<role^name>: N yuno(s) already registered at the new release, pending promotion: run deactivate-snap”). The marked rows stay in the preview so that yunetas upgrade-yunos still runs deactivate-snap for them; the CLI 0.19.4 counts them apart (see “Upgrade steps”). Test c_agent_find_new_yunos (the preview).

• Build: an archive installed with a changed content is now newer than the tests and yunos linked against its previous copy, so cmake --build build --target <test> relinks them. install() kept the archive’s build time, cut to whole seconds, and a test linked between a library’s build and its install looked newer than the new archive: a per-module test run could run the old library (7.25.4 too). An unchanged archive relinks nothing.

C_NODE, C_AUTHZ, C_TRANGER¶

• Every C_NODE and C_AUTHZ command comment starts with the yuno (except the “No permission ... in service” refusals, which name the service), and none reads gobj_log_last_message().

• import-db counts its errors by cause in data.errores ("node exists", "cannot create the node (see the log)"); 7.25.4 keyed them on gobj_log_last_message(), one key per record. A create refused for another cause than an existing node is a failure in every mode (skip counted it as ignored) and stops an abort import.

• treedbs, links, hooks and node hand their kw on with kw_incref() (7.25.4: json_incref(), released with KW_DECREF).

• activate-snap keeps the old snap active when the new one cannot be saved.

• C_TRANGER mark-tm-order [topic_name=<t> | all=1] (master, write), over the new tranger2_mark_tm_order(); with all=1 it skips, with an INFO, each directory of the store that is not a topic (no topic_desc.json, e.g. saved_schemas/). A topic that cannot be opened answers -1 (“<role^name>: cannot open topic ‘<t>’ (see the log)”).

• gc-assets answers a report (dry_run, assets, blobs, refused, blobs_refused) instead of the list of ids taken.

• C_TRANGER add-record works (7.25.4: a stub that answered -1 “Pending to review” and logged an ERROR with a stack). It appends a record that carries the topic’s pkey, on the master only, with the permission write: command-yuno id=<id> service=<tranger> command=add-record topic_name=pp record='{"id":"1","tm":1700000000}' answers “<role^name>: record added to topic ‘pp’, rowid <n>” with data: {topic_name, rowid, t, tm}. record is a dict or its json text; __t__ (0: now) and user_flag are optional. A replica answers -1 before the library is called. Test test_c_tranger.

• The pushes of a C_TRANGER live list carry its id as rt_id (7.25.4: no id), so a client with two lists open on one topic tells their records apart. Test test_c_tranger.

• instances no longer leaks its filter when it answers “What topic_name?”. An update-node with create whose create is refused logs “Cannot update node: it does not exist and it cannot be created (see the previous log)” (7.25.4 answered with gobj_log_last_message()).

• import-db counts a link it cannot make. A record naming a parent that does not exist was saved without the link and counted as a success ("link failure": 0); it is a link failure now. And import-db answers -1 when it aborts or anything fails, with a comment naming the counts, for example “<role^name>: import-db incomplete: 3 added, 0 overwritten, 0 ignored, 0 failed, 1 link failure(s) (see the log)” (ABORTED for an abort); a clean import answers 0 with the counts. 7.25.4 answered 0 with no comment (tests 15, 16 of c_node_link_events).

• export-db with no filename reads schema_version as a number: an integer version logged an ERROR with a stack (“path MUST BE a json str”) and was left out of the file name, which is now <treedb>-<schema_version>-<date>.trdb.json (for example treedb_link_test-1-<date>.trdb.json). A failed write of the export is logged (“Cannot write the export of the treedb”) and answers -1 (it answered 0). Test 17 of c_node_link_events.

• link-nodes / unlink-nodes split a child ref at its first ^: the topic is what comes before it (a topic name holds no ^), the id is all the rest, up to 255 bytes. A child whose id holds ^ or is 255 bytes long (legal in a topic without hooks, such as an MQTT client id) was listed by the treedb and could not be named: “Wrong child ref”. For example link-nodes parent_ref=groups^g1^users child_ref=users^client^7 links the user client^7. The parent ref keeps its three strict parts (test 18 of c_node_link_events).

• import-db names the peer of a content that is not json. It parsed the content as json of our own: an ERROR with a stack and a dump of the whole buffer (megabytes), naming no peer (7.25.4 too). It is a WARNING now (Protocol, “frame is not json”, peername, at most 256 bytes dumped), and the answer is still -1 (test 19 of c_node_link_events).

• snap-content reads only the topics of its treedb. 7.25.4 read any topic of the tranger by name, and its overview counted every topic, another treedb’s included, whose records carry the same snap numbers. A topic_name that is not a topic of the treedb answers -1, as in the other commands (treedb_is_treedbs_topic()), and the overview walks the treedb’s topics (test 20 of c_node_link_events).

• C_NODE’s EV_TREEDB_NODE_* feed and C_TRANGER’s EV_TRANGER_RECORD_ADDED ask read when the yuno sets enable_subscription_authz (see “Security”).

JS: gobj-js, gobj-ui, gui_agent, gui_treedb¶

• The versions: gobj-js 7.25.1 - 7.25.8, gobj-ui 7.25.6 - 7.25.22, gui_agent 0.22.79 - 0.22.98, gui_treedb 0.17.58 - 0.17.71 (SDK 7.25.4 shipped gobj-js 7.25.0, gobj-ui 7.25.5, gui_agent 0.22.78, gui_treedb 0.17.57). In this section a bare version is the package’s own; the SDK is written “SDK 7.25.4”. Each gobj-js and gobj-ui version named was published on npm, and each gui_agent / gui_treedb version was deployed, so a parenthesis about one of them (for example “gobj-ui 7.25.15 - 7.25.19 applied ...”) is about a version a consumer may have installed or run.

• Deployed to artgins.yunetacontrol.com and .ovh (gui_agent) and artgins.ytreedb.com (gui_treedb); every deploy console-checked (login, session, Schemas editor, forced reconnect, navigation and clicks during loads): 0 errors. Includes the fix of a regression of gobj-ui 7.25.6 that was live (navigating in the schema editor during a reload emptied the model).

• Schema editor: the loading screen is honest (body cleared, toolbar disabled, navigation waits for the load); a dialog opened on a model that a reload replaced is closed with a message and nothing stamped with the old model is written; a refused reload keeps the previous model; a transport drop ends the cut load or write and the reconnect reloads; stale answers are ignored by round; no load is asked out of session (the reconnect asks it); a late successful write reloads and keeps its marks. A reload that was refused is owed: the operator’s next change runs it first (the change is refused with a toast and the operator does it again once the schemas are in; a move, the editor’s own or the host’s, is not refused and reads there); any load that lands clears the debt (a Refresh included), and an import plan is dropped only by a load that lands. A confirmation that arrives with no model is refused as stale; the import plan lost to a reload is a warning and a toast.

• gobj-ui 7.25.7 / 7.25.8, the shell toasts (yui_shell_show_info/warning/ error): ONE toast per (kind, message) on screen. The same string of the same kind while one still shows restarts its time instead of stacking a copy (one close of a transport showed a column of identical “the connection dropped”); each caller holds it with its own handle and time, and it goes when every holder has closed or timed out (the ✕ still closes it for everybody).

• Shell modals: every ✕ (toast, modal, confirmation), MODAL_BACK and every CONFIRM_BTN carry a translatable title and aria-label; the schema editor’s export C/JSON switch is two buttons (aria-pressed), switched through the FSM (EV_EXPORT_VIEW); its confirmations pass the keys delete / cancel (they rendered in English in every locale).

• gobj-ui 7.25.13 / 7.25.14: in C_YUI_TREEDB_TOPICS, a write cut by the drop no longer asks for its topic out of session (the adapter logged “cannot route ‘nodes’ — not in session”). A drop marks the view, and the first edge that finds the transport in session reads every open topic table again, once: a node another writer created, changed or deleted during the drop shows. An “up” before the transport is in session, or with no drop before it, reads nothing. A form already answered by the edge is not answered a second time.

• gui_agent 0.22.79 - 0.22.81 (C_AGENT_TREEDB_LINK and the Schemas tab). The session closing ANSWERS every routed treedb request in flight (“the connection dropped”; a form stayed busy and the schema editor stuck until the page was reloaded). The deadline of a routed request starts at the controlcenter’s dispatch ack: 60 s, plus the base64 size of its __files__ at 128 KiB/s; a late answer is logged as a warning, and a late write that succeeded echoes its node event. Requests are numbered once for the page (with two treedb views mounted an answer could go to the wrong one). The Schemas tab: its save-schema / saved-schema rounds carry their id and another round’s answer is ignored; a session close settles the Save, the saved-schema round and the comparison; the apply deadline is one C_TIMER child, 30 s per step; a Save that answers only “nothing to save” while drafts are marked is said, and a Save that withdrew the saved schema says so (new i18n key). A hosted treedb view hears a session edge after its transport (EV_TRANSPORT_EDGE, a posted event), so a view is never told “connected” while its transport is not in session yet.

• gui_agent 0.22.87: an apply timeout decides with the answers that came. One treedb applied means restart, so kill / run / play goes on without the silent owners, and the toast names them and says their state is unknown (the tab of SDK 7.25.4 stopped and left the applied schema for the next unrelated restart). With nothing applied there is no restart, and the toast names the silent owners. New locale keys (en, es). 0.22.88: only the gobj-ui range (^7.25.14).

• gobj-js 7.25.1: kw_get_str() returns its default as given, as the C one does. It returned String(default), so a default of 0 or null came back as the truthy "0" / "null": kwid_get_ids() added the id "0" for a record with no id, and the ievent client named its target service "null" or "0" instead of its wanted_yuno_service (the server then used its main service). KW_CREATE stores a string default, and null for any other.

• gobj-ui 7.25.15, C_YUI_SCHEMA_EDITOR: a move sent by the host closes the dialog of the screen it left (the column or topic form, the import, the orphans), saying “the view moved: open the dialog again” (new consumer i18n key); a Save there answered “Event NOT DEFINED” and the edit was lost. A confirmation answered on another position is refused: a Yes to “delete this column?” asked on db/users and answered after a move to db2/users deleted the column of db2.

• gobj-ui 7.25.15, C_G6_NODES_TREE / C_YUI_TREEDB_GRAPH: a __graphs__ write that did not land (an error answer, a refusal by the transport, no session) is written again at the next Save (new input event EV_GRAPHS_WRITE_REFUSED {topic, graphs_load}); it was recorded as saved before it left. A refusal names the load it belongs to: C_G6_NODES_TREE counts its loads (each EV_CLEAR_DATA is one), sends graphs_load in the EV_UPDATE_NODE of __graphs__, C_YUI_TREEDB_GRAPH echoes it back on the three refusal paths, and a refusal from an older load is ignored with a warning (gobj-ui 7.25.15 - 7.25.19 applied a refusal answered after a reload to the fresh load). A host that sends no graphs_load is handled as before.

• The ranges: gui_treedb 0.17.58 - 0.17.61 took gobj-ui ^7.25.11 - ^7.25.14 (gobj-js stayed ^7.22.2); gui_agent 0.22.89 and gui_treedb 0.17.62 took gobj-ui ^7.25.15 and gobj-js ^7.25.1.

• gobj-js 7.25.2 / 7.25.3: kw_get_list(), kw_get_dict() and kw_get_bool() answer like the C readers. A value of the reader’s type is the answer; an absent key or a value of another type gives the default back (kw_get_list() / kw_get_dict() as given, kw_get_bool() as a boolean). kw_get_list() wrapped ({x: [1, 2]} gave [[1, 2]], a default of null gave [null]), kw_get_dict() turned a null default into {}, and kw_get_bool() read any value through Boolean() (the string "false" was true). kw_get_bool() logs a value that is not a boolean even without KW_REQUIRED, as C does (“path MUST BE a json boolean”, the kw traced); with KW_WILD_NUMBER it reads a number (0 is false), a "true" / "false" string in any case (else its decimal integer, as atoi() does: "0x1F" is false since gobj-js 7.25.5, 7.25.2 - 7.25.4 read it as hex) or null (false), and a list or a dict is false and logged (“path MUST BE a simple json element”), as in C: kw_get_bool(gobj, {on: "false"}, "on", true, kw_flag_t.KW_WILD_NUMBER) is false. KW_CREATE stores only a default of the right type, KW_EXTRACT takes out only a value of the right type, KW_REQUIRED logs a wrong type. kw_set_subdict_value() passed KW_REQUIRED where it meant KW_CREATE, and trace_json() no longer needs window (in a worker or node a KW_REQUIRED miss threw instead of logging). With no gobj, kw_get_list() / kw_get_dict() of gobj-js 7.25.2 - 7.25.4 logged a false “gobj bad type” (fixed in 7.25.5). No caller in the SDK or the project SPAs relied on the old answers; every caller of kw_get_bool() passes a boolean (__hard_subscription__, __own_event__, options.create).

• gobj-ui 7.25.16: C_YUI_SCHEMA_EDITOR hears a Refresh during a Save and runs it when the writes end (it started the load at once and the rest of the write queue was never sent, with no message). The Save of a form while a reload is owed keeps what was typed: the load that lands opens the form again on the schemas it read, with only the changed fields put back on top (two new consumer i18n keys). C_G6_NODES_TREE: a refused __graphs__ write keeps Save lit until a Save writes it, or until an echo of the __graphs__ topic shows it written (gobj-ui 7.25.19; 7.25.16 - 7.25.18 kept it owed after such an echo). The shell dialogs’ default labels are the i18n keys ok, yes, no, delete, cancel (they were English literals no locale holds); yui_install asks install this app. Every consumer SPA that shows these dialogs carries the keys (yunovatios gui-common got ok); yunomusica shows none of them.

• gui_agent 0.22.90: Apply is off while a Save of schemas is unanswered and refused if it arrives anyway (confirmed before the Save answered, the apply dropped the Save’s answers and Save stayed off for good). The Apply dialog closes, and says so, when a Save or a new round changes what it lists; an Apply outside ST_READY is refused and said; a late answer of an apply step is logged, not dropped; round numbers are counted per page, so a tab opened again cannot take an old tab’s answer. Five new locale keys (en, es). gui_agent 0.22.90 and gui_treedb 0.17.63: the ranges (gobj-ui ^7.25.16, gobj-js ^7.25.2); gui_treedb gets the ok key.

• gobj-ui 7.25.17, gobj-js 7.25.3, gui_agent 0.22.91, gui_treedb 0.17.64. In the treedb graph, a Save whose __graphs__ write the backend refused lit Save again only in tests: the real transports (C_IEVENT_CLI, gui_agent’s C_AGENT_TREEDB_LINK) answer with the request’s __md_command__ and not its record, so the view logged “a refused graphs write names no topic” and the next Save found nothing to write. The topic now travels in __md_command__ (graph_topic). In the schema editor, a write in flight also makes its body inert: the pointer was already blocked, but the keyboard reached the focused row and sent actions ST_SAVING does not declare (“Event NOT DEFINED”). A write marks the topic of its record, not the topic on screen (an import from the topics screen marked nothing, so no draft chip and no export warning). The reason a load failed changes language; a treedb or topic name in a notice is shown as it is (gobj-ui 7.25.17 translated it: a topic nodes read “Nodos”; fixed in 7.25.19). In gui_agent’s Schemas tab, a Save or a saved-schema round whose owner never answers ends after 30 s (a C_TIMER per round, like the apply steps) and names the silent owners (new keys save unanswered, saved schemas unanswered); it stayed open until the session dropped, and Apply stayed off with it. A Save cut by a drop reads the saved schemas again when the session is back, and since 0.22.94 a read that shows the Save landed clears “unsaved changes” (an error answer, or data that is not a list, proves nothing and keeps it, with a warning naming the owner; gui_agent 0.22.94 cleared it); a late save-schema / saved-schema answer is logged as a warning (gui_agent 0.22.91 - 0.22.93 dropped it with no log). The ranges: gobj-ui ^7.25.17, gobj-js ^7.25.3.

• gobj-ui 7.25.18, gui_agent 0.22.92, gui_treedb 0.17.65. The treedb topics and graph views publish EV_RECORD_WRITTEN when one of their writes lands, to tell the host which record was written. Its treedb_name and record came from the answer’s command frame, which carries back only the request’s __md_command__, so through C_IEVENT_CLI and gui_agent’s C_AGENT_TREEDB_LINK they arrived as "" and {}; a link or unlink in the graph also arrived with no topic, because it sent no __md_command__. The event takes treedb_name from the view and record from the node the store answers (the node as written; the deleted node for a delete; the child for a link), and a link or unlink carries the child’s topic and both refs (parent_ref, child_ref). No code read the empty fields, so nothing changes on screen. Every other command-frame read in gobj-ui, gui_agent and gui_treedb reads only what its request puts in __md_command__. The ranges: gobj-ui ^7.25.18.

• gobj-js 7.25.4: kw_get_int() and kw_get_real() answer like the C readers. KW_EXTRACT deleted the value before its type was looked at, so a value that was not a number was lost and the default came back; now only a value the reader answers with is taken out (kw_get_str() had the same ordering and takes out only a string now). A value that is not a number is logged (“path MUST BE a json integer” / “... a json real”) with or without KW_REQUIRED, as C does. KW_WILD_NUMBER, which was ignored, reads a boolean (1/0), a string (strtoll() base 0 for int: "0x1F" is 31; parseFloat() for real) or null (0); a list or a dict answers 0 and logs “path MUST BE a simple json element”. kw_get_int() truncates with Math.trunc() instead of parseInt(), which read 1e-7 as 1. No caller relied on the old behaviour. gui_agent 0.22.93 and gui_treedb 0.17.66 take gobj-js ^7.25.4.

• gobj-js 7.25.5, gobj-ui 7.25.19, gui_agent 0.22.94, gui_treedb 0.17.67. kw_get_str() logs a value that is not a string (“path MUST BE a json str”, the kw traced) with or without KW_REQUIRED, as C does, and gives the default back; a null value, or a key present with undefined, is never logged, and KW_REQUIRED still logs a missing path (the gobj-js 7.25.0 of SDK 7.25.4 logged it only with KW_REQUIRED). With no gobj, kw_get_str() no longer logs a false “gobj bad type”, and the three readers use the C wording. In gui_agent’s Schemas tab, Save, Differences and Apply work only in ST_READY: a re-discovery left the old tree on screen with the three live, and each click answered “Event NOT DEFINED in state” (SDK 7.25.4 too). The discovery has a 30 s deadline (new key discovery unanswered), and one that fails or finds no treedb removes the old tree and says why. A write in a data treedb no longer lights “unsaved changes” (only a write in treedb_system_schema does). Since 0.22.95 the three also need the session (toolbar_ready(): ST_READY and the agent link connected; the tooltip says not connected to an agent), and an Apply confirmed out of session is refused, with a toast, before the tree is taken down: in SDK 7.25.4 the Apply dialog could be confirmed after a drop, took the tree down and then failed to send (0.22.94 gated the three on the state alone). A Save or Differences out of session is said in a toast too. The treedb topics view publishes EV_RECORD_WRITTEN for a delete too, with the node the treedb answered, and created is true for its +New. C_YUI_NODE declares its navs’ EV_NAV_ITEM_CLOSE and EV_DRAWER_CLOSE_REQUESTED, and every nav event in ST_OFF; the topic form declares its json viewers’ EV_EXPAND_PATH (it answers EV_SUBTREE_ERROR, new key this part cannot be loaded here): each was a latent “Event NOT DEFINED in state”. Since gobj-ui 7.25.20 EV_SUBTREE_ERROR takes {path, error | i18n, by_design}: C_YUI_JSON draws an i18n key with t() and data-i18n, so the stub changes language, and logs a by_design refusal as a WARNING (a free-text error is drawn as it came and logged as an ERROR). The form and C_YUI_JSON_PAD (collapsed in the source) send by_design keys, and the “no session” of the topics, graph and gui_treedb views sends a key (gobj-ui 7.25.19 drew the form’s stub in the language it was clicked in, and logged an ERROR at each click). The toast key raw json viewer unavailable is in every app locale. C_YUI_UPLOT no longer reads stroke / fill with kw_get_str() (a function there is not logged). The consumers’ kw_get_str() calls were audited: none reads a value that is not a string. gui_agent 0.22.94 and gui_treedb 0.17.67 take gobj-js ^7.25.5 and gobj-ui ^7.25.19.

• gobj-js 7.25.6, gobj-ui 7.25.20, gui_agent 0.22.95, gui_treedb 0.17.68. kw_find_path() answers as C (SDK 7.25.4 too): a kw that is not a dict or a list returned 0, so kw_get_int() / kw_get_real() answered 0 and kw_get_bool() answered false instead of the default, and the log went through gobj_short_name(null) (“gobj bad type”); from gobj-js 7.25.2 on, kw_get_str() / kw_get_bool() also logged a second line. A null middle segment threw a TypeError where C gives the default. Now the answer is undefined, logged once (“kw must be list or dict: ‘<path>’”); a missing or null middle segment is logged only when verbose, a scalar one always, as the C recursion does. KW_CREATE no longer writes into a null kw. No caller passed such a kw. In the treedb graph, a __graphs__ create echo goes through apply_graphs_echo(), as the update echo does: in SDK 7.25.4 it rebuilt the saved copy of every topic from the live objects, so the unsaved edits of the other topics counted as saved and the next Save did not write them. The schema editor’s writes check the session first (SDK 7.25.4 too): out of session a write is not sent, the editor leaves ST_SAVING with “cannot reach the treedb”, and the reconnect reloads; with a direct C_IEVENT_CLI it waited in ST_SAVING with no way out (no deployed consumer was hit). Its refused-write toast gets the key, not a text translated before it. gui_agent 0.22.95 and gui_treedb 0.17.68 take gobj-js ^7.25.6 and gobj-ui ^7.25.20; gui_treedb sends a key for its “no session” stub.

• gobj-js 7.25.7, gobj-ui 7.25.21, gui_agent 0.22.96, gui_treedb 0.17.69. The raw-json viewer of C_YUI_TREEDB_TOPICS / C_YUI_TREEDB_GRAPH answers a drill asked out of session (a warning, no command sent, EV_SUBTREE_ERROR with the key no session) or refused by the transport (the refusal text); a refused drill of the whole document is also a toast. In SDK 7.25.4 the stub stayed on “loading” for the life of the viewer, even after the reconnect. gobj-js kw_set_dict_value() logs and answers -1 when a middle segment is null or a scalar (“segment ‘<k>’ is not a dict or a list: ‘<path>’”), with the kw unchanged, instead of throwing a TypeError (SDK 7.25.4 too): every typed reader with KW_CREATE over such a path answers its default, as C does (gobj-js 7.25.6 said so, and still threw with KW_CREATE). gui_agent’s Differences has a 30 s deadline (diff_deadline, a C_TIMER child) and a round number (diff_round): one owner that never answered kept the button off for the life of the tab, and an answer of an earlier comparison counted in the next (SDK 7.25.4 too); now the report shows what came, with the silent owners named at its top (new key differences unanswered, en and es), and a late answer is logged. Save’s title and aria-label say why it is off (no schema owner in this yuno, the busy reason, not connected to an agent) and change language, as Differences and Apply already did (gui_agent 0.22.95 left Save without it). The gui_agent console answers a click on a __collapsed__ stub of an answer (print-tranger expanded=1) with this part cannot be loaded here (a warning, nothing sent): the console was its viewer’s subscriber (the parent, by the CHILD model) and did not declare EV_EXPAND_PATH, so each click logged “Event NOT DEFINED in state” and the stub stayed on “loading” (SDK 7.25.4 too); type the command again with path=. gui_agent and gui_treedb take gobj-js ^7.25.7 and gobj-ui ^7.25.21.

• gobj-js 7.25.8, gui_agent 0.22.97, gui_treedb 0.17.70: a subscription that rewrites the kw gets its own (security; SDK 7.25.4 too). The port of the C fix (see “Security”). gobj_publish_event() gave every subscriber the same kw, and each subscription’s __local__ (kw_pop) and __global__ changed it: one subscription forged or stripped the event of every subscriber after it and of the publisher, and a later __filter__ was evaluated on the altered kw. C_IEVENT_CLI’s mt_inject_event() also wrote its ievent stack, __msg_type__ and the removal of __service__ into the published kw, so a local subscriber after the transport got the transport’s __md_iev__. Now a subscription with a non-empty __local__ / __global__ gets a shallow twin (Object.assign({}, kw): its own top level, the nested values shared), __global__ goes in as a copy (a receiver cannot change the subscription), and __filter__ and mt_publication_filter see the publisher’s kw; every other subscriber shares the publisher’s kw, at no cost. mt_inject_event() works on a shallow copy with __md_iev__ copied deep. No JS consumer sets __global__ / __local__ (gobj-ui, yunos-js, wattyzer, yunovatios, estadodelaire, hidraulia, yunomusica: 0 hits), so gui_agent 0.22.97 and gui_treedb 0.17.70 only take the fixed runtime (gobj-js ^7.25.8); gobj-ui’s devDependency moved to ^7.25.8, with no gobj-ui release. The rule is written in docs/doc.yuneta.io/api/js/events.md.

• gobj-ui 7.25.22, gui_agent 0.22.98, gui_treedb 0.17.71: a raw-json drill in flight when the session drops is answered (SDK 7.25.4 too). gobj-ui 7.25.21 answered a drill that could not go out, not one already sent: the transport answers nothing in flight on a close, a plain reconnect keeps the same view and viewer, and the stub stayed on “loading” for the life of the viewer (gui_treedb, wattyzer, yunovatios; gui_agent’s link answers on the close). C_YUI_TREEDB_TOPICS / C_YUI_TREEDB_GRAPH keep the drilled paths in flight and answer each one EV_SUBTREE_ERROR {path, i18n: "the connection dropped"} on the disconnect edge (EV_TRANSPORT_STATE, or the shell’s EV_CONNECTION_STATE for the topics view), so a click once the session is back asks again; a failure that lands for a path already answered is a warning. New consumer key the connection dropped in gui_treedb, wattyzer and yunovatios gui-common (gui_agent had it).

BREAKING¶

• A keyless tranger2_open_list() returns a list flagged load_failed / load_failed_keys when keys could not be read (7.25.4 skipped them and returned the list with no sign of it); more cases now fail a load: a key flagged at startup, and a record whose content cannot be read (it used to reach the callback as NULL).

• treedb refuses creates of unloaded ids, snapshot ops with a partial __snaps__, gc-assets asset rows with a partial asset topic or an active snap (treedb_gc_files() answers NULL and takes nothing; new treedb_gc_files2() answers a report).

• The agent’s audit record format changed: read-only commands are minimal, source replaces __md_iev__ (no longer written), __command__ is left out when it repeats the command text, and there is no content64 (its value is <N bytes sha256:HEX>, the sha256sum of the binary; a value that is not base64 becomes <N chars, not base64, sha256 of the text:HEX>), secrets are written as <redacted>, and write-tty is written as burst records {command, date, user, console, writes, bytes, until, source} with no kw. user, each field of a hop, console_purpose and the console name are redacted, and one of them longer than 1024 bytes is written as <N bytes, not scanned, sha256:HEX>. Tools that read the audit must accept both formats (files written before the upgrade keep the old one).

• yev_loop / gbuffer (API): gbuffer_t.addr is a struct sockaddr_storage (it was a struct sockaddr) with a new addrlen; gbuffer_setaddr(gbuf, addr, addrlen) takes the length and returns int (-1, logged, on a NULL gbuf or a bad length; it returned void), and gbuffer_getaddrlen() is new; yev_create_sendmsg_event() takes dst_addrlen; sock_info_t.addr is a struct sockaddr_storage (its addrlen was already there). Rebuild every user. yev_create_connect_event() / yev_rearm_connect_event() bind a non-empty src_url ("host:port", "[ipv6]:port", "schema://host:port"); a bad one, a failed resolution or a failed bind fails the connect (the in-tree callers pass NULL).

• mkrdir() returns -1 for a path of PATH_MAX or more, and over a path that exists and is not a directory; rmrdir() / rmrcontentdir() return -1 (logged) for a tree too long or too deep. find_files_with_suffix_array(), walk_dir_array() and get_ordered_filename_array() return -1 with the listing empty when an entry cannot be kept, and the last two also when the root is a directory that cannot be opened (7.25.4: 0; a root that is not a directory already answered -1); those three and walk_dir_tree() return -1 when a readdir() fails (7.25.4: 0, with the entries not read missing), and a subdirectory that cannot be read fails the walk. A walk callback that returns FALSE stops the whole walk (7.25.4: only its directory); a subdirectory that cannot be opened for a cause other than EACCES, ENOENT, ENOTDIR, ELOOP fails the walk, as does an entry whose lstat() fails for a cause other than EACCES / ENOENT (7.25.4 skipped both); a path that does not fit in PATH_MAX, or a tree deeper than 1024 levels, fails the walk (-1, logged). A log file whose mask has a day letter (DD, W, ZZZ) and no year, last written before today, is emptied at the first record after rotatory_open() (the yuno logs use W); an MM-only mask is judged by its month. Audit: the new secret names (and cookie_domain) are <redacted>, a string past the record’s scan budget (128 MB for all its strings) is written as <N bytes, not scanned, sha256:HEX>, and a record reaches the file at once. The agent’s dir-* commands answer -1 for a directory that cannot be listed (7.25.4: 0 and an empty list).

• rotatory: a log file renamed by another program is no longer noticed (a removed one still is): rotate yuno logs by copy and truncate, or remove them. The full-disk lines name the file (“rotatory(): stop logging to ‘<path>’ because full disk: ...”, was “rotatory(): stop logging because full disk: ...”), and a new line says when it resumes (“rotatory(): logging to ‘<path>’ again: ...”). The newfile callback (rotatory_subscribe2newfile()) runs for a new name or a size rotation only, not for the same file opened again. A mask with no date letter (a fixed name) is never emptied; an MM-only mask empties its file only in a new month. With rotatory_keep_all_old_files(), a size rotation whose rename fails keeps the file (it grows) and retries every minute of the monotonic clock. At a new day the file of the day before is not size-rotated.

• rotatory: exit_on_fail applies to rotatory_open() only; a later open that fails is printed once and tried again at the next record (7.25.4 exited the process).

• The agent removes audit files older than audit_keep_days (default 7; 0 keeps all) at every start and at each new audit file; the first start after the upgrade removes the backlog.

• gobj-c: the kw a command handler gets holds its own reference of a gbuffer (the parser increfs it, kw_update_missing()). A handler that took a second reference to work around the old double release now leaks it: take the buffer out of the kw (KW_EXTRACT) and use that reference.

• tranger2_write_topic_var() / tranger2_write_topic_cols() return -1 when the file cannot be written (7.25.4 ignored the write and returned 0); tranger2_create_topic() returns NULL, and does not open the topic, when a topic_version change cannot write topic_cols.json or topic_var.json (7.25.4 ignored the failure and opened it), and returns NULL, leaving nothing on disk or in memory, when any part of a NEW topic cannot be made (7.25.4 returned the half topic); the three md2 flag rewriters return -1 on a non-master; a revive whose store another process holds exits at on_critical_error (default: exit), any other revive failure demotes to replica; C_TRANGER’s master reads the effective state (it read the configuration); save_json_to_file()'s failed close is a CRITICAL at on_critical_error.

• New topics carry marks_tm_unordered in topic_desc.json, and a file of theirs whose tm goes back gets a <file>.tm_unordered marker beside its md2 (mark-tm-order writes them too); new tranger2_mark_tm_order().

• __system__ is projected whole from an installed literal: topics, columns and attributes the literal no longer declares are deleted there (with their instance history); a topic changed without a version raise now shows the literal’s content, with a warning. Seeding with no literal installed comes from the file, with c_schema_version 0 unless the file is the literal.

• apply-schema writes a new record, saved_schemas/<treedb>.applied.json, and refuses when it cannot write it; save-schema refuses a draft with no topics, and apply-schema a saved schema with no topics (without treedb_name, that refuses every treedb); save-schema refuses while a projection is unfinished (new record saved_schemas/<treedb>.unfinished.json); a failed create, update or link of the projection leaves it unfinished and retried; a second open-treedb is refused, and one whose schema is refused answers -1 (7.25.4: 0 “Treedb opened!”) -- so a refused agent schema stops the agent (exit 0, not relaunched); new answer texts for open-treedb / close-treedb / delete-treedb (“Treedb opened!” -> “<yuno>: treedb opened: ‘X’”, “Treedb closed!” -> “<yuno>: treedb closed: ‘X’”, “Treedb_name not found” -> “<yuno>: treedb ‘X’ not found”, ...); a client store locked by another process is not reconciled. The log order at open changed (the client tranger’s logs come first).

• msg2db: the pkey2s of an id that did not load whole whose newest message is in the damage or before it are absent instead of stale (new msg2db_id_incomplete()); while the damaged file is the current period’s, every new message of such an id is refused (msg2db_append_message() answers NULL).

• tr_queue / tr2q_mqtt: the tr_queue_t / tr2_queue_t structs grew (rebuild their users); trq_load() / tr2q_load() return -1 when the load did not read every pending message; trq_check_backup() / tr2q_check_backup() return -1 while the backup is refused, and when the backup fails (the queue keeps its topic). tranger2_backup_topic() opens the topic again after a failure that follows its close.

• timeranger2: tranger2_open_topic() returns NULL when the topic’s keys/ cannot be listed (7.25.4 opened it with no keys); a key whose directory cannot be listed is flagged "unlisted" and fails every load until it can be listed; an append into it lists it again first and returns -1 while it cannot. tranger2_list_topic_names() returns NULL (logged) when the store cannot be listed (7.25.4: [], no log); C_TRANGER mark-tm-order all=1 and the MQTT broker’s list-queues / clean-queues then answer -1.

• timeranger2: an append into a file flagged unreadable returns -1. A master cuts back an md2 that ends in a torn row (it writes the store at open). An md2 that 7.25.4 wrote after a torn row (also with content after its last row), or whose last two whole rows are not good records, is not cut: its key fails every load, on a master and a replica. A torn md2 is cut back with a WARNING; the other shapes log a CRITICAL (“md2 file of the key ends in a whole row that is not on a row boundary: written by 7.25.4 after a torn row; not cut, repair it by hand” or “md2 file of the key ends in a part of a row after a last whole row that is not valid: not cut, repair it by hand”), and an append into such a file is refused (“Cannot append record, its md2 file ends in a part of a row that must not be cut back: the append is refused”). A replica’s rt_disk update makes no cache cell for an md2 with no whole row yet.

• tr_treedb: a write whose save fails is taken back in memory and tells no event; treedb_autolink(), treedb_clean_node() and treedb_replace_links() return -1 when the save fails (7.25.4: 0); a forced treedb_delete_node() that cannot unlink a child, or delete its key, is refused and changes nothing (7.25.4 deleted the parent); the events of a link, unlink or update are told after the child’s save (7.25.4 told link events before it); new treedb_update_node_and_links(); treedb_autolink() refuses a ref whose hook links into another column than the one the ref arrives in (“fkey reference: its hook does not link into this column”; 7.25.4 linked it through that column); treedb_save_node() returns -1 for a node that no index holds (7.25.4 wrote it back into its deleted key), and for a node whose pkey2 value was changed in place (7.25.4 wrote a new instance and moved the node’s slot); treedb_create_node() indexes the pkey2 value its record holds (7.25.4: the raw kw value); a delete of a key with several instances counts, and with force unlinks, the children of every instance, and without force is refused while a parent’s hook holds another instance; treedb_delete_instance() takes the instance out of its parents’ hooks and hands its children to the primary; after a load, treedb_get_instance() of the primary’s own pkey2 value returns the primary node itself (7.25.4: a copy without links). A write that saves instances the caller did not ask it to write (the unrefs and children of a forced delete, a refused delete taken back, a failed unlink taken back, a snap shot that clones a tagged primary) leaves the newest record of each key on the instance that wrote it before, writing that record again last when another instance wrote a newer one (untagged, no event told): the next reload takes the same primary as without the write (7.25.4 made the instance saved last the primary).

• tr_treedb: treedb_create_node() refuses, for a topic with hooks, an id holding ^ or of NAME_MAX bytes or more; a dict hook refuses a node of another topic with an id it holds; decode_parent_ref() / decode_child_ref() return FALSE for a part that does not fit; treedb_delete_node() refuses a node whose child topic did not load whole, and counts every child its hooks hold (a dict hook’s child whose id holds two ^ was not counted, and the parent was deleted); treedb_delete_instance() answers -1 when a tombstone fails. C_NODE import-db: data.errores is keyed by cause ("node exists", "cannot create the node (see the log)"), and a create refused for another cause than an existing node is a failure in every mode (skip counted it as ignored) and stops an abort import.

• C_TREEDB: every answer of every command starts with the yuno (create-topic “<role^name>: topic ‘<t>’ created in treedb ‘<db>’”, was “Topic created!”; delete-topic “...deleted from treedb ‘<db>’”, was “Topic deleted!”; “<role^name>: treedb ‘<db>’ not found”, was “Treedb_name not found: ‘<db>’”; the -403 answers); a schema whose qualified ids collide (names with dots) is refused at open, save and apply.

• C_TREEDB answers carry new fields (withdrawn, stale, broken, withdrawn_at_open, unfinished_projection, stopped, and master and opened in treedbs rows) and saved changed meaning; withdrawn_at_open can carry the kind "left_by_older_release"; the “nothing to save” answers of save-schema carry data.store_ahead ({}, or the topics the store runs ahead of the file in use, with topic_version, running_version and path); delete-treedb answers data: {"treedb_name", "deleted": [ids]} and answers 0 for a treedb with nothing left (it was -1); every answer of save-schema carries data.left_by_older_release; EV_OPEN_TREEDB / EV_CLOSE_TREEDB answer -1 with an ERROR (they did nothing). The saved-schema / diff-schema diff carries a __topics_order__ row and a __cols_order__ row per topic (a reorder is a difference). save-schema and delete-treedb answer -1 while the __system__ tranger is stopped, and create-topic, delete-topic and apply-schema of a treedb while its own tranger is stopped (7.25.4 read the master of the stopped tranger: save-schema answered “nothing to save” and delete-treedb deleted nodes). save-schema writes into __system__ the position each node has in the saved schema, places a node whose order says nothing where the file in use declares it, and publishes a changed topic past the topic_version the store runs; the tie WARNING is logged when imposing too (with "imposed": 1). C_NODE snap-content answers -1 for a topic that is not of its treedb, and import-db of a content that is not json logs a WARNING (Protocol, with the peername) instead of an ERROR with a stack. C_NODE gc-assets data is a report, not a list; instances answers -1 on failure; import-db answers -1, with a comment, when it aborts or anything fails (it answered 0), and counts a link it cannot make as a link failure; export-db with no filename names the file <treedb>-<schema_version>-<date>.trdb.json; link-nodes / unlink-nodes take a child ref split at its first ^ (an id with ^ is accepted).

• The command comments of C_NODE and C_AUTHZ changed: they start with the yuno and name what they did, for example “Node update!” -> “<role^name>: Node update! ‘<id>’ of topic ‘<t>’”, “Nodes linked!” -> “<role^name>: Nodes linked, ‘<topic>^<id>’ to ‘<topic>^<id>^<hook>’”, “Node deleted” -> “<role^name>: Node deleted, ‘<id>’ of topic ‘<t>’”, “Snap deactivated” -> “<role^name>: Snap deactivated, treedb ‘<db>’”, “Snap activated: ‘<name>’” -> “<role^name>: Snap activated: ‘<name>’”, and “Cannot activate snap ‘<name>’: <last log message>” -> “<role^name>: snap not found: ‘<name>’” or “<role^name>: cannot activate snap ‘<name>’ (see the log)”.

• ip lists: C_TCP_S refuses at accept a peer in the yuno’s denied_ips (7.25.4 refused it only at the login of an authenticating gate); C_UDP_S drops the datagrams of a peer in denied_ips, or not in allowed_ips with only_allowed_ips (7.25.4 heard every peer); [::1] and [::ffff:127.0.0.x] are exempt like 127.0.0.x. is_ip_allowed() / is_ip_denied() look up an IPv6 peer by its ip without the port.

• C_UDP_S: its output event is EV_STOPPED (the event table declared the state ST_STOPPED, and nothing was published); a datagram the kernel refuses is dropped (it stopped the server); the EV_RX_DATA gbuffer always carries the peer as its label. C_IEVENT_SRV stops its protocol gobj when it is stopped. New yuno attribute enable_subscription_authz (off: nothing changes); C_NODE’s read carries the alias __subscribe_event__ (its authzs listing shows it), and so does C_TRANGER’s, whose EV_TRANGER_RECORD_ADDED is EVF_AUTHZ_SUBSCRIBE. C_UDP_S has a new stat, rxRefusedMsgs, and its refusal WARNINGs come at the first drop of a cause and then at most once a minute, with the new fields dropped, rxRefusedMsgs and next_warning_in_ms (7.25.4 had no refusal); a host that keeps the EV_RX_DATA gbuffer keeps it (the next read takes a new one). C_IEVENT_SRV keeps only __first_shot__ of a peer’s __config__ (__hard_subscription__, __own_event__, __rename_event_name__ and any other key are dropped with a WARNING), and a channel’s close removes its subscriptions by force, hard ones included. C_CHANNEL’s mt_enable starts its tree (gobj_start_tree()), and C_IEVENT_SRV’s mt_start starts its protocol gobj. gobj_unsubscribe_event() no longer counts a hard subscription it leaves in place as removed (it logs a WARNING).

• ip lists: the add- / remove- allowed / denied ip commands refuse a text that is not a numeric ip (7.25.4 stored it) and store the canonical form (2001:DB8::1 -> 2001:db8::1); a link-local address in allowed_ips needs its interface; remove-denied-ip / remove-allowed-ip of an ip that is not in the list answer -1 (7.25.4: success); the stored lists are normalised at the first start, and an entry that is not an ip is dropped (see “Upgrade steps”). C_IOGATE’s answer to a bad channel_name regular expression is “<role^name>: channel_name is not a valid regular expression: ‘<re>’” (was “regcomp() failed”).

• gobj-js 7.25.1 - 7.25.5: the typed kw_get_* readers answer like the C ones. kw_get_str() returns its default as given (it returned String(default)) and logs a value that is not a string; kw_get_list() no longer wraps its answer; kw_get_dict() no longer turns a null default into {}; kw_get_bool(), kw_get_int() and kw_get_real() read a value of another type as C does, and log it; KW_EXTRACT takes out only a value of the reader’s type. gobj-js 7.25.6: kw_find_path() answers undefined for a kw that is not a list or a dict (it answered 0, so kw_get_int() / kw_get_real() gave 0 instead of the default) and for a missing or null middle segment (it threw). gobj-ui 7.25.20: EV_SUBTREE_ERROR takes {path, error | i18n, by_design} -- a host that sends a translated error should send the key as i18n (a free-text error is still drawn as it came, and logged as an ERROR); a by_design refusal is a WARNING. See the JS section.

• yuno_agent: find-new-yunos marks the rows already registered at the new release, and create=1 skips them (it failed on each); the dir-* failure answer is “<role^name>: cannot list ‘<dir>’, see the log”. MQTT broker: list-queues queue=<name> answers -1 for a queue that cannot be opened or read whole (7.25.4: 0).

• gobj-c: kw_set_dict_value() overwrites a key that exists (7.25.4 kept the old value) and returns -1, logged, when it writes nothing (a scalar or null in the middle of the path, an index outside its list, an empty path). New kw_twin(). gobj_publish_event() gives a subscription with a non-empty __local__ / __global__ its own kw_twin() of the event: such a subscriber no longer sees, nor changes, what another one changed, and the __filter__ of every subscription sees the publisher’s kw (7.25.4 applied each __local__ / __global__ to the one kw of every subscriber). gobj_subscribe_event() of a subscription that matches a hard one returns the hard one, with a WARNING (7.25.4 made a second one), and a hard subscription over a plain one replaces it. A log call leaves errno as it found it, and a failed mkrdir() leaves the cause in errno; rmrdir() / rmrcontentdir() return -1 on a readdir() error (7.25.4: rmrcontentdir() returned 0).

• C_IEVENT_SRV: of a peer’s subscription only __filter__, the allowed __config__ keys and the __global__ keys that do not start with _ (nor gbuffer) are kept; the rest is dropped with a WARNING. New attributes max_subscriptions (default 5000) and max_subscription_size (default 16384): a subscription beyond them is refused. The withdrawal of a subscription is filtered the same way, and matches one with a __global__. C_IEVENT_SRV / C_IEVENT_CLI mt_inject_event() work on a twin of a shared kw. C_GSS_UDP_S: new max_channels (1024), max_pending_bytes (8 MB) and max_frame_size (1 MB, the old size of every frame buffer, which now starts at 4 KB); a frame longer than max_frame_size is delivered cut, without an ERROR.

• C_TCP: a stop always publishes EV_STOPPED once, also the stop of a client that is already disconnected (7.25.4 published nothing there and kept the connect event); it can come inside gobj_stop(). A write that cannot be created or started drops the connection, with an ERROR (7.25.4 ignored it, and the connection hung).

• C_TRANGER: add-record appends (master-only, write; 7.25.4 answered -1 “Pending to review”); the pushes of a live list carry rt_id, its list_id; close-rt, close-iterator, close-list, get-page and get-list-data of a handle opened by another session answer -403. A handle’s owner is (src, user): the channel of the command and its __username__, so through the agent (command-yuno, one link for every operator) a handle is its user’s, and a relayed command without a user owns nothing it did not open.

• C_TREEDB: save-schema publishes every topic whose saved place is not the file’s (an order row in changes), writes the order of a node with more than one parent as 9999 (says nothing) and names it in data.places_not_written, and answers -1 with data.twins when two topics of a treedb (or two columns of a topic) have one name; saved-schema’s draft_changed names the topics whose places the draft shifts; a failed open-treedb keeps the saved schema (withdrawn_at_open.saved_schema_version 0). tr_treedb: treedb_link_nodes() refuses a topic under a name its treedb already has (“Treedb already has a topic with this name”); an unlink clears the parent’s ref in every instance of the child, and a delete counts (without force) or clears (with force) the instances of a child that name it and that no hook holds.

• timeranger2: tranger2_delete_key() returns -1 when the stat() of the key directory fails with anything but ENOENT (7.25.4: 0, and the key was dropped from the cache and announced); a topic whose key listing meets a stat() failure (no d_type) does not open. tr2q_check_backup() does not back up while messages are queued (answers 0); tr2q_move_from_queued_to_inflight() answers -1, the message kept queued, when its content cannot be read.

• yev_loop: the close of an fd takes back the submissions of other events on it that the kernel has not taken; those events complete as STOPPED, -ECANCELED. yev_loop_destroy() does not free a zero-copy send whose notification has not come after 5 s (a WARNING).

• rotatory: the size limit is compared in bytes (7.25.4: whole megabytes, so a limit of 8 MB rotated at 9 MB).

• yuno_agent: create-yuno answers -1 for a release name longer than NAME_MAX (7.25.4 stored it cut and answered 0).

• gobj-js 7.25.7: kw_set_dict_value() answers -1, logged, when a middle segment is null or a scalar (it threw). gobj-js 7.25.8: the publish twin rule, as in C.

• C_IEVENT_SRV: the back-metadata stored with a peer’s subscription is the reversed top record of the frame’s ievent stack only (7.25.4 stored the frame’s whole __md_iev__), and a subscription whose routing is bigger than max_subscription_size is refused. A session frame without its routing closes the channel (7.25.4 processed it). A frame that repeats a subscription the channel holds leaves it as it is (no second mt_subscription_added(), no second first shot; 7.25.4 deleted and made it again), and one that overrides a held subscription replaces it. A (un)subscription of an event that is not public is refused and the channel goes on (7.25.4 answered -1 and left the channel deaf); a command or stats request without its command, or with a service that is not a string, gets a negative answer. Its peer-frame logs are WARNINGs at most one each 10 s per kind, with suppressed (7.25.4: a line per frame, most of them ERRORs).

• gobj-c: “subscription(s) REPEATED, will be deleted and override” and “Hard subscription REPEATED, the one there is kept and returned” carry no stack, and their kw is capped to 256 bytes. A subscription is matched with its kw as it is stored (__hard_subscription__, __own_event__ and __rename_event_name__ taken out, __original_event_name__ put in with a __global__), in gobj_subscribe_event() and gobj_unsubscribe_event(): a repeated __own_event__ / __rename_event_name__ subscription replaces the one there, and an unsubscribe with the same kw removes it (7.25.4 made a second one, which could not be withdrawn).

• C_TCP_S: a refusal by the ip lists is logged at the first refusal of each cause and then at most once a minute per cause, with refused, refusedConnxs and next_log_in_ms (7.25.4: one INFO per refused connection); new stat refusedConnxs.

• C_UDP_S: a udps:// url is refused at start (ERROR, -1; with exitOnError, the default, the yuno exits with 0); use_ssl is always false. A read that cannot be started again stops the server, with an ERROR (7.25.4 went on, deaf); a stop with a datagram in flight ends in ST_STOPPED with EV_STOPPED.

• C_GSS_UDP_S: a published frame carries its peer’s label and address. EV_SEND_MESSAGE sends to the gbuffer’s address, or else to the known peer its label names, and answers -1, with an ERROR, for a gbuffer with neither (7.25.4 logged “UDP channel NOT FOUND” for a send by address, and a send by label had no address).

• MQTT (C_PROT_MQTT2): an ack of the wrong packet (a PUBACK for QoS 2, a PUBCOMP for QoS 1 or before the PUBREC, a PUBREL of the wrong QoS in the client) is a protocol error: a WARNING, the connection closed (an MQTT 5 peer gets DISCONNECT 0x82), and the message kept in flight (7.25.4: an ERROR, and the message removed as delivered). “Message not found in trq_out_msgs” is a WARNING (was an ERROR). The out window of a queue is the lower of the broker’s max_inflight_messages and the client’s Receive Maximum, also when the broker’s is 0. list-queues qos= combines with the pending= condition (7.25.4 replaced it).

• C_TREEDB: save-schema writes the order of a node that hangs from more than one parent as 9999 (says nothing), so a node that stops being shared is placed by the file of the parent that remains.

• timeranger2 / gobj-c: without d_type, find_keys_in_disk() asks lstat(): a symbolic link in keys/ is not a key (7.25.4 followed it), and an EACCES entry is a key, as with DT_DIR; find_files_with_suffix_array() lists an entry whose lstat() fails with EACCES (7.25.4 skipped it). tr_queue / tr2q_mqtt: a queue without topic takes a topic the tranger has open again, and tries the open again when its cause may be gone (see “Data loss and integrity”).

• yev_loop (internal, no API change): get_sqe() clears the fd and the user_data of every submission entry it hands out, so an entry of the queue is told by the event that owns it, never by what an earlier operation left in the ring slot.

• yuno_agent audit: see the audit record bullet above (user, the hops, console_purpose and the console name redacted).

• Log texts -- match on the new ones if you alert on them:

  • timeranger2: “Cannot read last record, md2 file corrupted” is gone (see the md2 bullets above). “Cannot read first/last record of md2 file” are now “Cannot read a record of md2 file, read FAILED” or “..., short read” (with row: first, last, or end / before last in the torn-tail check); a truncated md2 or content logs “... short read” instead of “read FAILED”, and a write that stops part way logs “... short write: the file size limit or the disk is full” (with written / expected) instead of “... write FAILED”.

  • timeranger2: “Bad data, anystring2json() FAILED.” is now “Bad data, the content of the record is not json”, or “Cannot read the record, this process has not the memory to parse its content (MEM_MAX_BLOCK)”.

  • timeranger2: “Cannot mark md2 file as unordered, file_id too long” / “..., a reload will misread its time range” are “Cannot mark md2 file, file_id too long” / “Cannot mark md2 file, a reload will misread its time range”.

  • timeranger2: “next rowids not consecutive” / “previous rowids not consecutive” are “next segment begins before the row just read” / “previous segment ends after the row just read”.

  • timeranger2: “Master lock NOT retaken after a stop, go on as not master” is three texts, “Master lock NOT retaken after a stop: cannot open the lock file, go on as not master”, “...: another process holds it, ...” and “...: flock() FAILED, ...”.

  • timeranger2: the ERRORs “what id?” and “Disk already exists” of an rt disk are the WARNINGs “Invalid rt id (empty)” and “rt disk id already in use by the same creator, refused”.

  • timeranger2, new: “Cannot re-create topic_cols.json for a new topic_version: the topic keeps its version, and is not opened”; a key or a topic that cannot be listed: “key directory cannot be listed when its cache was built: every load of the key says load_failed”, “The history of the key is not whole: its directory could not be listed when its cache was built”, “Cannot append record, its key cannot be listed: its row would follow rows no cell counts”, “Cannot open topic: its keys cannot be listed”, “Cannot list the keys of the topic” (and “, readdir() FAILED”), “New records of the key not read: its directory cannot be listed”, the INFO “key directory listed again: its files are counted, and the key is not flagged”; “Cannot list the topics of the store” (and “, readdir() FAILED”); a backup: “Backup of topic failed: the topic is opened again as it was, not backed up” (WARNING), “Backup of topic failed, and the topic cannot be opened again”, “Cannot back up topic, its directory not found”, the CRITICAL “Backup of topic failed, and the backup cannot be moved back: the data of the topic is in the backup”; tr_queue / tr2q_mqtt: “Queue backup failed: the queue goes on in its topic, not backed up”, “Queue backup failed, and the queue has no topic”, the ERROR “Queue without topic, it cannot be opened” and the INFO “Queue topic taken again”; a create: the CRITICAL (at on_critical_error, after the removal) “Cannot create topic: it is not whole, what was made is removed”; a failed delete_key: “Cannot index the key again after its files changed: the filtered iterator is empty”, “Cannot delete key, stat() of its directory FAILED” (the key is not deleted, dropped from the cache nor announced), “Cannot tell the rt_disk feeds that a key was deleted, opendir() of disks/ FAILED”, “Cannot tell every rt_disk feed that a key was deleted, readdir() of disks/ FAILED”; “Cannot list the keys of the topic, stat() FAILED”; the CRITICAL “Cannot append record, its md2 file cannot be opened: its content was cut back”; the ERRORs “md2 file of the key unreadable when its cache was built: every load of the key says load_failed” and “The history of the key is not whole: a md2 file of it could not be read when its cache was built”; tr_queue / tr2q_mqtt: the ERRORs “Queue backup refused: its last load did not read every pending message” and “Queue loaded without some of its messages: its first_rowid is not moved nor saved”; the CRITICAL “Cannot cut back a md2 file that ends in a part of a row: the file is damaged”; the ERRORs “Cannot append record, its file is flagged unreadable: its row would follow rows no cell counts” and “Cannot mark the topic: it is not marked; the markers written stay, and the cells read keep their whole ranges”. “Cannot list the keys of the topic, stat() FAILED” is no longer logged for EACCES (the entry is a key, as with d_type).

  • msg2db, new: the ERRORs “msg2db: a key whose history did not load whole: only the messages newer than the damage are served, a pkey2 whose newest message was not read is ABSENT and its state unknown (msg2db_id_incomplete)”, “msg2db: the damaged file of the key is the file of the current period: every new message of the key is REFUSED until the file is repaired or the period changes” and “msg2db: load_failed_keys holds an item that is not a string: that key is not reloaded”, and “Msg2Db topic NOT FOUND” (msg2db_id_incomplete()).

  • tr_treedb: new ERRORs “A write that did not reach the disk could not be taken back whole in memory: ...”, “A refused delete cannot put back a child it had unlinked: ...” and “Cannot write again the newest record of a key: at the next open another instance of it is the primary”, and the CRITICAL “Cannot write again the newest record of a key after its clone: at the next reload the photo is its primary” (a snap shot).

  • tr_treedb: the ERROR “Child node without fkey field” (one per node, at every open) is the WARNING “An fkey column is filled by no hook: its refs link nothing”, once per column per open, with nodes_with_refs. “tranger2_delete_instance() FAILED” is gone, and so are “wrong array child hook type” and “md_treedb not found” of the delete guard. New: “Wrong reference: a part of it is too long”, “Invalid ‘id’: it holds a ‘^’, the separator of a reference”, “Invalid ‘id’: too long to be part of a reference”, “Cannot link, the dict hook holds a node of another topic with this id”, “A dict hook holds a node of another topic with this id: this link is not loaded”, “Child data not found in dict parent hook: its slot holds a node of another topic”, “Cannot link, the reference the child has is too long”, “Cannot delete node: a topic its hooks hold did not load whole, a child that did not load may hang from it”, “Cannot delete instance, a row of it cannot be tombstoned: the instance stays, its newest rows alive”, “Cannot create node, its id has records on disk that could not be loaded”, “Cannot shoot a snap: snaps did not load whole, the active snap is unknown”, “Cannot activate a snap: snaps did not load whole, the active snap is unknown”, “Cannot deactivate a snap of too many active ones, it stays active on disk”, “Cannot save a node that is being deleted”, “treedb topic loaded WITHOUT the whole history of keys that cannot be read: ...”, “Cannot build the reference of a node: a part of it is too long, or holds a ‘^’”, “Cannot save a node that no index holds: its record would bring back what was deleted”, “Cannot save a node whose pkey2 value changed in place: its record would be another instance”, “Cannot put an instance back into the hook of a parent: its slot holds another node”, “A dict hook holds a node of another topic with this id: the child of a deleted instance is not handed to the primary”, “Cannot hand the children of a node without treedb_name, topic_name or id”, “Cannot look for the parents of a node without treedb_name or id”, “Treedb already has a topic with this name” (with id and sibling_id; the column text now carries sibling_id too), “A write taken back cannot save again an instance that stopped naming a parent: on disk it names it no more”. “Cannot delete node: has down links” carries children and unheld_instances. “Child data not found in list parent hook” / “... dict parent hook”, “Duplicate fkey on load, deduping parent hook” and “delete_primary_node() FAILED” are no longer logged for another instance of the key (a relink or unlink of a sibling instance, an instance held through a list hook, a key only the secondary indexes hold).

  • tr_treedb: treedb_autolink()'s “update_node, new link: parent node not found” is “fkey reference: parent node not found”, the text of treedb_replace_links(). “cannot delete asset, a snapshot still links it” is also “cannot delete asset, cannot tell whether a snapshot links it (see the log)” when the snapshots cannot be read.

  • gobj-c: mkrdir()'s “Not a directory” is “Not a directory: the path exists and is not a directory” (7.25.4 never logged it: its check could never be true). New: “Cannot list directory, no memory for an entry” (find_files_with_suffix_array()), “Cannot list directory tree, no memory for an entry” and “Cannot list directory tree, the directory cannot be opened or read” (walk_dir_array()), “Cannot list directory, readdir() FAILED” (find_files_with_suffix_array()), “Cannot read directory, readdir() FAILED” (walk_dir_tree()), “Cannot close json file, what was written may be lost” (save_json_to_file(), a CRITICAL). The directory walks: the ERRORs “Path too long, the directory cannot be walked”, “Tree too deep, the directory cannot be walked”, “Cannot list directory, stat() FAILED” (find_files_with_suffix_array()) and “stat() FAILED, the directory cannot be walked” (was “stat() FAILED”), the WARNING “Cannot open subdirectory, it is skipped” (7.25.4 logged nothing for EACCES / ENOENT and the ERROR “Cannot open directory” for another cause); the root that cannot be opened is the ERROR “Cannot open directory”. gobj_unsubscribe_event(): the WARNING “Hard subscription not removed, only gobj_unsubscribe_list() with force removes it”; gobj_subscribe_event(): the WARNING “Hard subscription REPEATED, the one there is kept and returned”; it and “subscription(s) REPEATED, will be deleted and override” carry no stack, and their kw is a compact dump capped to 256 bytes (7.25.4: the whole kw, with a stack). New: “Cannot remove directory, readdir() FAILED” (rmrdir()) and “Cannot remove the content of directory, readdir() FAILED” (rmrcontentdir()). kw_set_dict_value(): new ERRORs “path empty”, “json_object_set() FAILED”, “json_array_set() FAILED”; a scalar middle segment logs “long path” (its “short path” is gone). kw_twin(): “kw to twin must be an object”, “json_copy() FAILED”. A caller’s CRITICAL after a failed mkrdir() (“Cannot create TimeRanger subdir. mkrdir() FAILED”) now names the real errno (it said “Success”).

  • rotatory (stdout and syslog): “_rotatory(): vfprintf() FAILED, <err>” is “_rotatory(): fwrite() FAILED, ‘<path>’, <err>”; “_rotatory(): Cannot rename ‘<path>’ to ‘<old>’, <err>” ends with what follows (“, the file is emptied” or “, the file is kept and grows, the rename is tried again every minute”) and is printed once until “_rotatory(): the size rotation of ‘<path>’ works again”. New: “_rotatory(): writing to ‘<path>’ again”, “_rotatory(): N pieces of ‘<path>’ in one day, the last one is replaced”, “_rotatory(): Cannot empty ‘<path>’, <err>”, “_rotatory(): ‘<path>’ is open again”. “_rotatory(): Cannot open ‘<path>’ file, <err>” (and “Cannot create ‘<path>’ file” / “directory”, “_rotatory_truncate(): Cannot open ...”) is printed once until the file opens again, and no longer ends the process.

  • C_UDP_S, new: the ERRORs “Cannot send datagram: dropped”, “UDP: read FAILED, the server stops listening”, “UDP: no memory for the next read, the server stops listening”, “UDP: the read cannot be started again, the server stops listening”, “Cannot start the read of the UDP server” and “A secure url (udps://) is not supported by C_UDP_S: there is no DTLS” (the ERROR “Cannot set ‘trace_tls’, ‘crypto’ is not a dict” of C_UDP_S is gone); the WARNINGs “UDP: datagram refused by the kernel, dropped”, “UDP server stopped: the datagrams waiting to be sent are dropped”, “UDP_S: Ip denied, datagram dropped” and “UDP_S: Ip not allowed, datagram dropped” (the last two at the first drop of each cause, then at most once a minute, with dropped, rxRefusedMsgs and next_warning_in_ms).

  • C_TCP_S, new: the INFO “TCP_S: Ip denied”. It and “TCP_S: Ip not allowed” are logged at the first refusal of each cause, then at most once a minute per cause, with the new fields refused, refusedConnxs and next_log_in_ms (7.25.4: one line per refused connection); the msg2 of “TCP_S: Ip not allowed” is the same text (it began with a globe sign).

  • C_IEVENT_SRV, new: the ERROR “No permission to subscribe event”; the INFO “UNSUBSCRIBING event never subscribed, its subscription was refused” for the withdrawal of a refused subscription, and the WARNING “UNSUBSCRIBING event matches no subscription of this channel” for any other unsubscribe that matches nothing (both in place of the ERROR “No subscription found” with a stack); the WARNINGs “SUBSCRIBING config keys a peer may not set, ignored” (with keys) and “SUBSCRIBING config is not a dict, ignored”; the WARNINGs “SUBSCRIBING keys a peer may not set, ignored” (its keys name the __local__, any stray key and each dropped __global__`<key>), “SUBSCRIBING refused, bigger than max_subscription_size” (field, size) and “SUBSCRIBING refused, the peer holds max_subscriptions” (once, until the peer is under the cap). The dropped-keys WARNINGs, the size refusal and both UNSUBSCRIBING texts are logged at most once per kind, per channel, per 10 s, with suppressed (the no-match WARNING dumps at most 256 bytes of the kw, with kw_size); “No permission to subscribe event” is logged at the first refusal of each service and event on a channel. New: the WARNINGs “SUBSCRIBING refused, its routing is bigger than max_subscription_size”, “SUBSCRIBING repeated, the one held is kept”, “SUBSCRIBING overrides one held, it is replaced”, “Frame without its routing (md_iev ievent stack), channel closed” (in place of the ERRORs “md_iev NOT FOUND” / “md_iev stack NOT FOUND”, with a stack) and “Request without the command or stats it asks, refused”, with the answer “<role^name>: request without the command or stats it asks”. “It’s not my role” / “It’s not my name” (ERRORs) are the WARNINGs “It’s not my role, channel closed” / “It’s not my name, channel closed”, with the routing capped. These ERRORs are now WARNINGs at most one each 10 s per kind and channel, with suppressed and username: “event ignored, dst_service not authorized for this channel”, “event ignored, service not found”, “SUBSCRIBING event ignored, not PUBLIC or PUBLIC event”, “UNSUBSCRIBING event ignored, not PUBLIC or PUBLIC event” and “Not authorized to request stats of a different service”; the WARNING “Service not found” is limited in the same way. The peer’s strings in them are capped to 128 bytes, and the service named in their answers (“Service not found: ‘<service>’”, ...) to 60.

  • C_GSS_UDP_S, new: the WARNINGs “Too many peers, datagrams of new peers dropped” (on the transition), “Too many bytes in unfinished frames, datagram dropped with the unfinished frame of its peer” and “Frame without end within max_frame_size, delivered cut” (at most once per 10 s, with a count), and the ERROR “EV_SEND_MESSAGE without a peer: no address, and its label names no known peer; dropped”; the ERROR “gbuffer_append() FAILED” of a frame that did not fit, the frame buffer’s “no memory”, and the ERROR “UDP channel NOT FOUND” of a send by address are gone.

  • C_TCP, new: the ERRORs “Cannot start a write: the connection is dropped” and “Cannot create a write: the connection is dropped”.

  • C_TRANGER, new: the WARNING “Handle of another session, refused” (kind, id, src, user), the ERROR “Handle not registered, its owner user cannot be stamped” (an internal check) and the -403 answer “<role^name>: <kind> ‘<id>’ is not yours: another session opened it”; add-record answers “<role^name>: record added to topic ‘<t>’, rowid <n>”, “<role^name>: What record? It must be a dict with the pkey of topic ‘<t>’”, “<role^name>: cannot add the record to topic ‘<t>’ (see the log)” and “<role^name>: tranger ‘<name>’ is READ-ONLY, this yuno is not its master: add-record runs on the master” (its ERROR “TODO pending to review” and answer “Pending to review” are gone).

  • MQTT (C_PROT_MQTT2 client): the WARNING “removing an inflight qos2 dup message” is “QoS 2 message received again (dup): it replaces the copy waiting for its PUBREL”; new ERROR “Cannot load the content of a queued message: it stays queued”; a client’s QoS 2 PUBREL no longer logs “QoS mismatch”. “QoS mismatch” of an ack of the wrong packet, “Unexpected message state for QoS 2” and “Message not found in trq_out_msgs” are WARNINGs (MSGSET_MQTT, with client_id and peername), where 7.25.4 logged ERRORs.

  • C_IOGATE: “regcomp() failed” is “<role^name>: channel_name is not a valid regular expression: ‘<re>’”.

  • C_YUNO ip lists, new: the WARNINGs “ip list entry renamed to the form a peer is looked up by” and “ip list entry dropped, it never matched a peer” (with entry and the cause), the ERROR “ip list is not a dict”; the answers “<role^name>: ‘<ip>’ stored as ‘<canonical>’”, “<role^name>: ip ‘<ip>’ is not in allowed_ips” / “... is not in denied_ips”, and the refusal of a text that is not an ip, with its cause.

  • MQTT broker, new answers: list-queues “<role^name>: cannot list the topics of the store, see the log”, “<role^name>: cannot open the queue ‘<name>’, see the log” and “<role^name>: the messages of the queue ‘<name>’ cannot all be read, the list is PARTIAL, see the log”; clean-queues “<role^name>: cannot list the topics of the store, nothing cleaned, see the log”.

  • yuneta_agent, new: the WARNING “Audit: bad md_iev from a peer, written as empty”, the ERRORs “audit scan: a replacement behind the copy” and “Audit: a field of a peer cannot be written” (internal checks: nothing of that text is written); the dir-* answer “<role^name>: cannot list ‘<dir>’, see the log”; find-new-yunos marks a row “already registered, pending promotion (deactivate-snap): create-yuno ...”, comments “<role^name>: N yuno(s) already registered at the new release, pending promotion: run deactivate-snap”, and logs the ERROR “yuno release name too long”; create-yuno answers -1 “<role^name>: Yuno ‘<role>.<name>’: release name too long (‘<binary version>’ + ‘<config version>’)” after that ERROR (7.25.4 stored the name cut, with no log).

  • C_TREEDB: “Topic from C differs from the one in use, but its topic_version is not higher: not applied” is “Topic from C declares other columns than the store runs, without raising its topic_version past it: the store keeps running its own”; “Schema from C takes over the file in use while system holds a draft saved over it: ...” is gone, replaced by “Schema from C withdrew work on the schema at open”; a record write failure logs “Cannot write a record of saved_schemas/”; “Treedb schema not projected in system” is gone (a delete-treedb of a schema that is not there answers 0). New: the WARNINGs “TreeDB schema ids moved to qualified names only in part: ...” and “Schema from C has the schema_version of the dynamic schema in use but another content: ...” at every open that ties (7.25.4: only when c_schema_version differed); the ERRORs “EV_OPEN_TREEDB is not implemented: ...” / “EV_CLOSE_TREEDB is not implemented: ...”; C_NODE “Cannot write the export of the treedb”; the WARNING “Schema file in use declares other columns than the store runs, at a topic_version behind the store’s ...” (with path; it ends “... to keep what runs, edit the topic in system to those columns, then save-schema and apply-schema; to run the file’s, raise its topic_version above running_version (and the schema_version) in the schema from C”); the ERRORs “Topic of a saved schema not found in system, its place is not written”, “Column of a saved schema not found in system, its place is not written” and “Topic of a saved schema not found in system, its topic_version is not written”; the “nothing to save” answers of save-schema name a topic the store runs ahead of the file (“...; the store runs ‘users’ ahead of it with other columns, which the draft cannot say: ...”). The tie WARNING carries "imposed": 1 on an imposed open. C_NODE import-db of a content that is not json logs the WARNING “frame is not json” (Protocol, peername) in place of the ERROR “json_load_callback() FAILED” with a stack. C_TRANGER mark-tm-order answers “<role^name>: cannot open topic ‘<t>’ (see the log)” for a topic that cannot be opened. The ERRORs “Schema refused: two topics of the treedb in system have the same name, unlink or rename one of them” / “Schema refused: two columns of a topic in system have the same name, ...” (with name, first, second), the ERROR “Schema refused: two elements have the same qualified id in system (a name with a dot), rename one of them” (with id, first, second), and the save-schema answer “<role^name>: cannot save the schema of ‘<db>’: the topics ‘<topic1>’ and ‘<topic2>’ have the same name ‘<n>’, and a schema keeps one per name: unlink or rename one of them”; a save comment may end “; N node(s) hang from more than one parent and get no place of their own (one order cannot say a place in each): see places_not_written”; the INFO “Saved schema kept: the open that installs the schema from C did not open; the next one that installs a schema from C and opens withdraws it”.

  • C_NODE: “Cannot save the node after its links (autolink)” is gone; a create logs “Node created, but its links cannot be saved (autolink): the node stays without them”. An update-node of a node that does not exist logs “Cannot update node: it does not exist”, or with create “Cannot update node: it does not exist and it cannot be created (see the previous log)” (7.25.4 logged the last message of the process, or “treedb_create_node failed”). New: the ERRORs “Cannot delete a node on a READ-ONLY replica”, “Cannot link nodes on a READ-ONLY replica” and “Cannot unlink nodes on a READ-ONLY replica” (7.25.4 had only “Cannot write a node on a READ-ONLY replica”).

  • yev_loop: “io_uring_get_sqe() FAILED” is gone. New: the WARNINGs “Submission queue full and the kernel takes nothing: kept for the next cycle” and “Submissions the kernel did not take: submitted again at each cycle”; the ERROR “Submissions not taken by the kernel for many cycles of the loop: their operations wait”; the INFO “Submissions taken by the kernel again”; the CRITICALs “No memory to keep a submission” and “No memory to keep a completion: submission handed over as it is”; the ERROR “No memory to keep a submission: <what did not happen>”; the ERROR “Loop destroyed with events whose completions did not come: freed” (with cancel_submitted), and before it, when the cancel cannot be submitted, “Submission queue full: the cancel of the events left is NOT submitted, their completions may not come”. A connect with a bad src_url logs the ERROR “Bad src_url: cannot bind the connect” (new), “getaddrinfo() src_url FAILED” (unchanged) or “bind() src_url FAILED” (was “bind() FAILED”). “Cannot start event: sendmsg addr NULL” is “Cannot start event: sendmsg addr NULL or bad addr length”. New: the WARNING “An fd is closed with submissions of other events on it that the kernel did not take: taken back, completed as canceled”, the ERROR “...: dropped, the event will not complete”, the WARNING “Loop destroyed with zero-copy sends whose notification did not come: NOT freed, the kernel may still read their gbuffer”, and the ERRORs “Cannot replace the gbuffer of an event with an operation in the kernel” (with a stack) and “io_uring_submit_and_wait_timeout() FAILED”.

  • tr2migrate: “Bad data, json_loadfd() FAILED.” is “Bad data, the content of the record is not json”; a json file it cannot load logs the texts of load_json_from_file().

Known limitations¶

• default: {} placeholders are dropped by save + apply, so a required column whose literal really declared 'default': {} loses it.

• getaddrinfo() runs synchronously inside the event loop (connect, source bind, listen): a lookup blocks every gobj of the process, and a dead first nameserver costs ~6 s per lookup (3 s x 2 per query). The cache of 7.8.2 makes it one lookup per host per TTL.

• OIDC discovery requires end_session_endpoint: against Auth0, and some Cognito setups, which do not publish it, discovery fails; set token_endpoint and end_session_endpoint explicitly for those IdPs.

• Each Live card of a C_TRANGER opens its own rt_disk feed, one inotify instance each: many Live cards can use up fs.inotify.max_user_instances (128 by default), as they did on one node.

• An md2 truncated to 0 rows behind the yuno’s back loses its rows, as in 7.25.4 (now with a warning); check the .json size before repairing.

• With enable_subscription_authz off (the default), the EV_TREEDB_NODE_* feed of a treedb and the EV_TRANGER_RECORD_ADDED feed of a C_TRANGER reach any authenticated user, while C_NODE’s and C_TRANGER’s commands ask read with every gate off. A project yuno that publishes the feed again under its own service (the db_history* yunos) is checked only if it flags its events EVF_AUTHZ_SUBSCRIBE and aliases a permission.

v7.25.4 (2026-09-23)¶

The 2026-09-23 review of the 2026-09-22 treedb/timeranger work¶

A third, read-only review of the fixes of 2026-09-16 and 2026-09-22 (six reviewers, repros against outputs/lib) found 12 mediums and ~35 lows that no test caught. All of them are fixed below, each with a test that was red before where one could be written.

BREAKING

• treedb on a replica: treedb_create_node() is refused up front, and treedb_store_files() refuses bytes (“Cannot store a file, NO master”). gobj_update_node() on a C_NODE replica answers NULL for any non-volatil update, before anything moves.

• tranger2_open_rt_disk() answers NULL for an id that a live feed of the topic already uses (any creator) and for an id longer than NAME_MAX. A refused id from a peer is a WARNING without a stack, and “Cannot open rt” is no longer logged on top of it.

• tranger2_open_list() of one key answers NULL when its history load fails. Iterators carry two new fields, segments_stamp and load_failed.

• Scans: a t condition does not end a scan inside a file marked .unordered, and a tm condition never ends a scan early. Rows that used to be lost are returned now.

• After tranger2_stop(), opening a topic again takes the master lock again, or turns the tranger into a non-master if another process holds it.

• Snapshot guards and treedb_delete_instance() refuse (-1) when they cannot read. treedb_activate_snap() answers -1 when a save fails, __clear__ included, and C_NODE deactivate-snap passes the -1 on.

• C_NODE: delete-node with options.ignore_snaps asks create as well as delete. EV_TREEDB_UPDATE_NODE is no longer a PUBLIC event: a peer could inject it through C_IEVENT_CLI and write with no permission. A refused update-node no longer carries the topic desc.

• C_AUTHZ: EV_ADD_USER, the disabled write of EV_REJECT_USER and EV_IDP_USER_CREATED refuse on a replica (-1, logged).

• C_TREEDB: apply-schema answers data (named: {treedb_name, applied, saved_schema_version, in_use_schema_version}; unnamed: a list of rows {treedb_name, result, comment, data}), and an unnamed apply writes nothing if any applicable treedb fails. A C literal newer than the file in use takes over a saved-but-not-applied draft in __system__, with a warning.

• C_TRANGER: open-rt refuses an rt_id longer than NAME_MAX. Open/close failures answer an explicit comment instead of gobj_log_last_message().

Security and integrity

• C_AUTHZ ac_reject_user: a rejected user whose disabled write fails (replica, failed save) kept its live sessions. The sessions are dropped from the node read before the write, whatever the write answers.

• rt_disk feeds: disks/<id> is keyed by id alone, so a client with read could open a second feed with the id of the treedb’s own feed on a replica and remove its directory by closing its own feed. That replica then stopped following the topic, and nothing was logged. One id, one feed.

• treedb on a replica: an update with a file column wrote a blob into the master’s store and moved links in memory before refusing. The refusal comes first now. The autolink path of mt_update_node checks its save.

• tranger2_stop() left the fds it closed in fd_opened_files, and any tranger2_topic() afterwards cleared __closed__, so the shutdown closed the same fd numbers again, which could belong to someone else by then. The stop marks them -1; only a real reopen revives the tranger.

• apply-schema writes the file in use through a temporary file, fsync and rename (it truncated it in place). save_json_to_file() closes the fd when the write fails.

Correctness

• C_TREEDB: draft_changed diffs the draft against the SAVED file when one newer than the file in use exists: after a Save, the editor said “unsaved changes” until Apply, or for ever on an imposed treedb. An unnamed apply-schema is all-or-none. prune_schema drops the meta-schema placeholder default: {}. save-schema guards the __system__ master. Explicit failure messages.

• timeranger2: late rows in a marked md2 file are found in both directions, by the iterator index too. tranger2_iterator_get_page() re-reads an unfiltered iterator’s segments only when the key’s cache changed. treedb_delete_instance() reads its rows with an iterator (a pkey2 value holding / logged two errors per delete). topic_var.json is replaced through a temporary file, so the rowid counter is never missing on disk. NULL file ids are refused in the three remaining sites. A replica’s page that cannot read a deleted key’s rows says so. fs_watcher: a missing ROOT stays an error.

• tr_treedb: a ref in a column its hook no longer fills is stale and is removed with a warning. Such a node could not be deleted, not even with force.

• C_TRANGER: a no_rt list is freed after its topic closes (it leaked). The keys watch has its own creator (<gobj>^keys), so a client feed named <it>^__keys__ can no longer be closed by get-page. It records only the keys the iterator pages. A multi-key iterator counts its unfiltered parts live at every page, so newest-first sees rows appended after the open.

• C_NODE: links_refused is local to mt_update_node, so a nested update cannot reset it.

• The __md_tranger__ contract of the append is stated exactly: the record is changed in place (a carried dict is dropped before the dump; the dict is attached when a realtime list takes the record). New test test_append_md_contract.

New tests: test_stop_reopen, test_append_md_contract, test_rt_disk_multi_feed (feed hijack), tr_treedb_files 20, tr_treedb_hook_rename 5, a walk of C_TREEDB’s command table refusing a denied user plus replica refusals, N11 with a real save over a dict-shaped file, test_command_delete_user 8-9, test_late_record in both directions, and the N1 traversal test given a real loop and a reachable victim.

gobj-ui 7.25.5, yunos-js gui_treedb 0.17.57 / gui_agent 0.22.78¶

• kernel/js/gobj-ui -> 7.25.5:

  • EV_DRAFTS replaces the host’s draft marks instead of adding to them.

  • A form write no longer hangs after a websocket drop in ANY host: yui_shell_set_connection_state() publishes EV_CONNECTION_STATE, and C_YUI_TREEDB_TOPICS listens to it on its shell. wattyzer and yunovatios did not forward EV_TRANSPORT_STATE.

  • Pending writes are keyed by topic and serial.

  • The pkey2 of an update is sent as the record had it, not through a datetime-local widget, which loses the seconds.

  • The DST limit of form_time_value.js is written down.

  • Wiring tests on a document double.

• yunos/js -> gui_agent 0.22.78:

  • Apply is counted per TREEDB (data.applied, or the row result on a 7.25.3 node) and restarts the yuno only if something was applied.

  • Drafts are gathered fresh per saved-schema round.

  • A 60 s deadline on each two-hop request, and routing errors of mt_command_parser count as failures.

  • Toasts stay re-translatable.

• yunos/js -> gui_treedb 0.17.57: placeholders and titles of the Rows options, and the “records were gone” text says what happened.

• Deployed to every consumer; hidraulia (v1) untouched. Every deployed SPA was loaded with a real login, a websocket session and one forced reconnect. Zero errors, after a pre-existing C_IEVENT_CLI trace-level lookup in yunomusica was fixed.

C_TREEDB: apply-schema asks create-delete, save-schema write¶

• BREAKING (authz). 7.25.3 meant to make apply-schema ask create-delete (it replaces the schema of a treedb whole, like create-topic / delete-topic) and put the permission on save-schema instead: an operator with only write could Apply but no longer Save, not even a dry_run. Now save-schema asks write and apply-schema asks create-delete, as 7.25.3’s notes said. test_c_treedb_system_schema checks both with a user granted everything but create-delete.

yunos-js gui_treedb 0.17.56¶

• yunos/js -> gui_treedb 0.17.56: discovery re-runs only for a connection whose C_NODE services lack master (0.17.55 counted C_TRANGER too, which never has one, so every session re-ran the whole discovery), and a finished scan no longer logs C_TIMER^scan_timer_N: GObj NOT RUNNING (a gobj_stop() after clear_timeout(), which already stops it). Deployed to artgins.ytreedb.com.

v7.25.3 (2026-09-23)¶

BREAKING in this release (flagged after the fact, 2026-09-23)¶

These behaviour changes shipped in 7.25.3 without the flag:

• tranger2_append_record() no longer attaches __md_tranger__ to the caller’s record. Read the out-param instead: md2_record_ex_t gained g_rowid (the key’s global rowid). The dict is attached only to what a realtime list takes. md2_record_ex_t grew: any object built against the old header must be rebuilt (the md2 format on disk did not change).

• treedb_update_node() / gobj_update_node() answer NULL on a replica (saved update) and when the save fails; they used to answer the node.

• C_TRANGER open-iterator / open-rt / open-list on an id already open answer -1, not 0.

• C_NODE activate-snap answers result 0 on success (7.25.0-7.25.2 answered the activated snap’s id).

• C_AUTHZ write commands answer “READ-ONLY replica” up front on a replica.

• Permissions of the schema commands: the notes below say apply-schema asks create-delete and save-schema keeps write. As shipped, the check landed on save-schema instead (a write-only user could Apply and could not Save). Corrected in the next release.

gobj-js 7.25.0¶

• kernel/js/gobj-js -> 7.25.0: the version back in line with the SDK, no runtime change since 7.22.2 (a comment in lib_treedb.js, a test of kwid_new_dict()). Published and tagged so the documented anchors of lib_treedb.js point into a tag again; JS API index repinned.

gobj-ui 7.25.4, yunos-js gui_treedb 0.17.55 / gui_agent 0.22.77¶

• The JS half of the 2026-09-22 lows: kernel/js/gobj-ui -> 7.25.4 (a delete whose rows or cards went while the question was open tells the person; a string time column is written as ISO text; new consumer i18n key), yunos/js -> gui_treedb 0.17.55 (pre-0.17.53 connections re-scanned, whole-topic Rows card never persisted, placeholder follows the language) and gui_agent 0.22.77 (late apply answers ignored, Save in flight logged, backticks in change ids, Apply tooltip). Deployed to every consumer. JS API index regenerated.

The lows of the 2026-09-22 review, C side¶

• timeranger2: a topic_desc.json that does not load answers NULL at once (it went on with topic == NULL through seventeen spurious errors), and its load carries no exit bit: a failed READ never exits, and the name may come from a peer (the TOCTOU between the existence check and the load ends in an error, not an exit). A topic opened again after tranger2_stop() clears __closed__, so the shutdown closes what it opened.

• C_TRANGER: open-iterator / open-rt / open-list on an id that is open answer -1 “already open” (an open that opens nothing was a success-shaped 0 with no data); the epoch a multi-key iterator is judged by is one counter for the process, not per gobj (two C_TRANGERs over one tranger could hand the same number to two openings); the parts of a multi-key iterator are opened under their own creator (<gobj>^parts), so a client’s one-key iterator named <id>^<key> no longer collides with them (test in test_c_tranger).

• treedb: a hook column of type string is refused at the __system__ write (it was blessed there and refused by every link into it, after the unlink of a replace); a required column flagged now is the clock’s and is not asked of the caller; a snapshot guard that cannot READ the key’s records says so (“cannot tell whether a snapshot holds it”) instead of naming a snapshot; update-node’s refusal names its contract (“some of its links were NOT changed ... that column was left as it was”), and the flag it reads survives an update-node re-entered through a treedb event.

• C_TREEDB: prune_schema_node() keeps a column’s default as written, [], {} and null included; apply-schema asks create-delete, as create-topic / delete-topic do (save-schema keeps write); the replica guards of save-schema / apply-schema / saved-schema read the tranger’s EFFECTIVE master when the treedb is open (a master that could not take the store in exclusive opened as a replica); an unnamed command over several treedbs names the ones that FAILED in its comment.

• C_AUTHZ: every write command (create-user, update-user, enable-user, disable-user, delete-user, set-user-pwd, set-max-sessions) answers “READ-ONLY replica” up front on a replica; set-max-sessions answers the refusal of its update, and the session drop of a rejected user logs the refusal of its volatile update.

• Docs: shoot-snap after deactivate-snap waits for a reload (treedb.md); apply-schema’s permission (data.md).

gobj-ui 7.25.3, yunos-js gui_agent 0.22.76¶

• kernel/js/gobj-ui -> 7.25.3: the schema editor rebuilds its drafts from the host (EV_DRAFTS, N13). yunos/js -> gui_agent 0.22.76: the Schemas tab reads draft_changed off every saved-schema answer and sends it to every editor under its tree; both SPAs on gobj-ui ^7.25.3. JS API index regenerated.

timeranger2: a marked md2 file is not read whole at every wake-up of a follower¶

• A file the master marked .unordered (a late record, M16) was read whole by load_cache_cell_from_disk(), and a follower loads the cell again on every append of the master: each append cost the follower every row of that file, 32 bytes a row (N12 of the 2026-09-22 review). The cell in memory already holds the range of the rows it counted, so only the rows after them are read (widen_cell_from_rows() from rows + 1) and the two ranges are joined. test_late_record: a marked file that keeps growing serves the new rows, the late one and the old ones alike.

C_TREEDB: saved-schema says which topics the draft changes¶

• saved-schema answers draft_changed, the topics whose draft in __system__ differs from the file in use, computed with the same diff a save-schema uses (draft_changed_from_rows()). The schema editor kept that mark in the memory of one session only, so a reload of the page, a reconnect or its Refresh lost the chip, the banner and the export warning while __system__ still differed from the file (N13); gobj-ui 7.25.3 rebuilds them from this answer, which gui_agent 0.22.76 hands it. Red test in test_c_treedb_system_schema.

gobj-ui 7.25.2, yunos-js gui_agent 0.22.75¶

• kernel/js/gobj-ui -> 7.25.2: a topic form’s write is answered every way it ends, the transport closing and a write asked with no session included (N8 of the 2026-09-22 review), and a form busy twice comes back whole (N9). yunos/js -> gui_agent 0.22.75: an apply-schema that one owner refuses after another applied goes on to the restart and says who refused (N10); both SPAs take gobj-ui ^7.25.2. JS API index regenerated.

C_TREEDB: the diff of a save reads a schema file whose topics are a dict¶

• save-schema (and saved-schema, diff-schema) diff the draft against the file in use through diff_treedb_schema(), which read the file’s topics with kw_get_list(): a file whose topics is a DICT keyed by name -- what a node opened with impose_c_schema off wrote before 7.25.0, from get_treedb_schema() as it was -- read as no topic at all, so every topic was “changed”, nothing to save never answered, and every topic_version and the schema_version were bumped and written again at each save (N11 of the 2026-09-22 review). The topics are read as a list whatever shape the file holds them in (schema_topics_as_list()), a dict’s topic taking its name as id; and schema_topic_version() no longer logs “kw must be list or dict” for a topic a dict-shaped file does not hold. Red test in test_c_treedb_system_schema: the same file in use as a list and as a dict gives the same changes.

C_NODE: activate-snap answers result 0; C_AUTHZ: enable-user answers the refusal¶

• activate-snap passed the return of treedb_activate_snap() through as the command’s result: the id of the activated snap since the 7.25.0 side fix that made the library return it (0 before, unless switching snaps). ycommand takes its exit code from result, and a client testing for 0 read a success as a failure. The result is 0 on success (N6 of the 2026-09-22 review; the agent, which tests >= 0, never noticed).

• enable-user handed the return of gobj_update_node() to the response as it was: a refused update (a replica, any refusal of the treedb) answered result 0, “User enabled”, with no record. It answers -1, as disable-user does since 7.25.0 (N7). Red tests in test_c_node_authz and test_command_delete_user.

• And underneath, in the library: treedb_update_node() answered the node whatever treedb_save_node() said, and moved the node in memory before the save. On a replica the append is refused (“NO master”) and the update “worked” until the next reload -- pattern 1 of the 2026-09-21 review, which the command-level guards of 7.25.0 covered for C_NODE’s commands and not for gobj_update_node() (C_AUTHZ, the agent). A saved update on a replica is refused BEFORE the memory moves, with “Cannot update node, NO master”; a memory-only update (save FALSE) goes on; and a failed save answers NULL.

C_TRANGER: a dead id is free again, a backward page counts from the live end, a key born again is a deleted key¶

• The three registries (iterators, realtime feeds, stateful lists) drop an entry whose handle went with its topic: at mt_stop, after delete-topic, when get-page answers “closed with its topic”, and when open-iterator / open-rt / open-list meet the id again. A stale entry answered “already open” (result 0, no data) to its own id after a close and reopen of the topic, a delete-topic + create-topic or a stop/start of the service, and every get-page after it -1, until a close-iterator by hand (N3 of the 2026-09-22 review; the identity resolution of 7.25.0 closed the use-after-free and kept the entries).

• get_single_key_page() cuts a backward window with the LIVE row count of the key, the one the page’s total_rows carries, where it used the count frozen at the open: once the key grew, “newest first” skipped the newest rows and a page past the old count came back empty (N4). A filtered iterator pages its index, which does not grow.

• A multi-key iterator (rkey) keeps ONE rt_mem over the topic, only_md and fed to nobody, for its key_deleted callback: a key deleted and created again between two pages was judged intact by its presence in the topic’s cache and paged with the row count of the dead one, result 0 and no log; it answers -1 “was deleted” now, like a one-key iterator (N5).

• Tests: test_c_tranger opens the same ids again after a topic reopen, pages a growing key backward, and deletes and re-creates a key under an rkey iterator (red before).

timeranger2: an unfiltered iterator pages the key as it is¶

• tranger2_iterator_get_page() takes an unfiltered iterator’s segments from the cache again before every page. They were taken at the open only, while total_rows was the live count: the rows appended since the open were in no segment, so a page past the count of the open came back empty and the pages it announced could not be read. A filtered iterator keeps its index and its segments, as before.

timeranger2: the id of a disk feed stays inside its topic¶

• tranger2_open_rt_disk() refuses an id that is empty, ., .. or holds /, with “Invalid rt id (path metacharacters not allowed)”. The id is the directory <topic>/disks/<id>/, and a follower rmrdir()s it before creating it (and again on close): the rt_id of open-rt and the list_id of a realtime open-list reached it from the wire unconfined, under the read permission, so rt_id=../../../../<dir> removed that directory as the yuno’s user. Same family as the topic-name rule of 7.25.0, which confined every OTHER name from the wire. A backtick is accepted: an rt id is not a kw path segment, and treedb names its own feeds with them. Red test in test_topic_path_traversal.

C_NODE: update-node with create_only asks for create¶

• The create permission check of cmd_update_node was keyed on options.create alone, while mt_update_node turns options.create_only into create: a caller with update and no create created nodes with {"create_only": 1} (the GUI sends both, so its path was checked; a raw ycommand was not). Both options ask for create now when the node does not exist. Red test in test_c_node_authz.

timeranger2: the append returns its metadata in the out-param, g_rowid included¶

• md2_record_ex_t has a new field, g_rowid: the key’s GLOBAL rowid, files included, the number __md_tranger__ stores as g_rowid. Every place that fills the struct fills it (the append, get_md_by_rowid(), the disk feed), so a callback or a queue that copies the struct carries it. It was the one thing the out-param did not return, and the only reason a caller had to read __md_tranger__ off the record after the append: treedb did, in two places, and now reads md_record.g_rowid.

• tranger2_append_record() no longer adds __md_tranger__ to the record for the caller. It adds it only to the record it hands to a realtime list that takes it (one that wants the key and is not an only_md feed), built once, right before the first such callback. It used to decide by the record’s refcount, which says who HOLDS the record, not who reads the dict: the queues, c_tranger and webstats hold it for other reasons and paid for a dict they never read (the queues then kept it in memory per queued message until msg_iev_clean_metadata() stripped it on send). Callers hand over their only reference and read the out-param. Pays off for a db_tracks ingesting raw_tracks with no realtime list open: +13.5% appends/s in test_topic_pkey_integer (+21% together with the change below).

• A __md_tranger__ the record carries in is dropped before the content is written. Nothing stripped it, so a record appended again with the dict inside (webstats stores the report it keeps each run; an add-record of c_tranger with a record taken from a get-page) wrote the metadata of the EARLIER record into the .json as content: eight lying integers per record, invisible on read because the load overwrites the key, and permanent on disk.

• tranger2_read_record_content() refuses a __t__ it cannot name a file for, and a body it cannot read, instead of attaching the metadata to a NULL record; and the g_rowid it attaches is the struct’s, where it used to put the file-relative rowid there.

• C_TRANGER’s realtime-only feed (open-rt) stops rebuilding a __md_tranger__ over the one the append attaches; the consumer gets the same eight fields get-page emits.

timeranger2: an append names its file once¶

• tranger2_append_record() computed the record’s file id (gmtime + strftime of the filename_mask) three times: for the .json, for the .md2 and for the cache cell. It is computed once and handed to the three; get_topic_wr_fd() takes the file id instead of __t__. The data, the metadata and the cache cell now name the same file by construction (the cell used to recompute it from the masked time). +4.6% appends/s in test_topic_pkey_integer. The write of a user flag and tranger2_delete_instance() name the file once too: they computed it for the existence check and again for the descriptor.

• mark_file_unordered() logs an error instead of silently truncating a <file_id>.unordered marker name that does not fit, and still flags the cell as unordered in memory: a marker that cannot be written is not a file that is ordered, and without the flag every later late record logged the same error again.

• The three writers that name a record’s file (the append, the write of a user flag, the payload wipe of tranger2_delete_instance()) refuse when get_file_id() fails (gmtime() rejected the __t__), instead of going on with an empty file id: the record landed in keys/<key>/.json + .md2, hidden from every load, with a cache cell whose id was "", and the append answered 0.

timeranger2: an append reuses the integers of the cache it updates¶

• tranger2_append_record() updates the key’s cache on every append (the file’s cell and the key’s totals: 10 integers). They were replaced with a new json_integer() each time -- 10 allocations and 10 frees per append. Now the integer already there is set in place (set_cache_int()); nothing holds a reference to them (readers copy the value or deep-copy the cell). Every writer of those fields goes through it, the range widening of a cell and the key totals included, so the invariant has one implementation. +4.8% appends/s in test_topic_pkey_integer (179.8k -> 188.3k without a realtime list, 158.3k -> 165.8k with one).

webstats: each top client says whether fail2ban banned it¶

• webstats reads fail2ban_log_path (/var/log/fail2ban.log) and its last rotation (.1, or the newest dated one on RHEL) and puts on each row of Top clients and Top offenders "banned": {at, jails, ban_number, ban_time} or false. Restore Ban and Unban are not counted; Increase Ban gives the ban number and length. Record version 3 (banned on the rows, a fail2ban block with the bans by jail).

• false only when the log was read: an unreadable log leaves the rows empty and says so in Needs attention. Needs attention also warns when none of the top offenders with 3+ probes was banned -- a jail watching nothing.

tools/fail2ban: escalating bans for the probe jail, and a readable fail2ban.log¶

• install-probe-ban-escalation.sh: bantime.increment on yuneta-nginx-probe (1d, 2d, 4d, capped at 1w) plus dbpurgeage = 30d, so fail2ban remembers the earlier bans. Chosen over the stock recidive jail, which reads the weekly-rotated fail2ban.log and misses a scanner that returns after a rotation -- as both returns measured on a node did. fail2ban-client -t before and after, the previous state restored on failure. Opt-in: dbpurgeage is server-wide policy.

• make-fail2ban-log-readable.sh: root:adm 0640 and yuneta in adm, as Debian ships it; RHEL ships the log 0600.

webstats: the top clients are named -- country and organisation, from RDAP¶

• The first whois_rows (10) rows of Top clients and Top offenders now carry who the address is: country, the organisation that holds the network, the network name and its range, looked up over RDAP (the JSON successor of whois, over HTTPS). One service answers for every address: RIPE redirects an address it does not hold to its registry, and the lookup follows it (verified against the five registries and IPv6).

• New state ST_LOOKING_UP between reading and reporting. One lookup at a time, each by a C_PROT_HTTP_CL built for it and destroyed once its C_TCP says it stopped; a whois_timeout bounds each one. A lookup never stops the mail: a failure leaves {"error": ...} on the row, a WARNING in the log and lookup failed: ... in the mail.

• The stored days are the cache: an answer younger than whois_cache_days (30) is taken from them, not asked again. Failures are never cached.

• Private, loopback and link-local addresses are never asked. Everything in an RDAP answer is HTML-escaped before it reaches the mail.

• Record version 2: adds whois on the rows and a whois summary (cached / looked_up / failed), printed under Sources.

• New attributes whois_enabled, rdap_url, whois_rows, whois_cache_days, whois_timeout; new trace level whois. The node must reach the registries on port 443.

v7.25.2 (2026-09-22)¶

gobj-c: gbuf2json_from_peer() -- a frame from a peer that is not json is a warning¶

• New gbuf2json_from_peer(gobj, gbuf, peer_gobj): parses json RECEIVED from a peer and, when it is not json, logs one WARNING (MSGSET_PROTOCOL, “frame is not json”, the peername of the transport under peer_gobj, the parser’s error, the length) with a dump capped at 256 bytes and no stack -- the decoder-severity rule. gbuf2json(gbuf, 2), which callers used for that, logs an ERROR with a stack and the whole buffer, and names no peer: an internet scanner on a yunovatios gate left exactly that.

• Switched: c_qiogate (the ack of the remote gate -- which also went on with a NULL ack and logged more errors; it returns now), logcenter (a truncated UDP datagram is a warning, not an error with a stack) and dba_postgres. c_node keeps gbuf2json(): it reads its own store.

• Test: gbuffer/test_gbuffer_guards (json back; bad bytes give one warning and no error, read from a log handler of the test).

C_TREEDB: saved-schema on a treedb with nothing saved no longer logs an error¶

• The console asks saved-schema of every treedb it shows, and most have no saved schema: the missing file reached kw_get_int() as NULL and logged “kw must be list or dict” (path: schema_version) on each call -- seen in the agent of wattyzer after 7.25.1. apply-schema, save-schema and treedbs read the same files the same way; all five sites go through schema_version_of(), 0 for a file that is not there. Test: c_treedb_system_schema asks saved-schema and treedbs before any save (red against 7.25.1 on that log).

v7.25.1 (2026-09-22)¶

C_TREEDB: impose_c_schema is configuration, not a persisted attribute (BREAKING)¶

• The attribute loses SDF_PERSIST. The value a yuno runs with is its configuration: its main.c ('global': {'treedbs.impose_c_schema': false}) or its config file. A value saved by the command outranked the configuration, survived every new binary, and lived nowhere a deploy could see. A file saved by an older release is ignored (the loader reads only SDF_PERSIST attributes).

• set-impose-c-schema is removed, and the permission impose-c-schema with it. Kept as an in-memory switch it could never act: the value is read when a treedb opens, a treedb opens when its yuno starts (close-treedb refuses while the yuno plays), and a restart reads the configuration again. To change the value, change the main.c or the config file and deploy.

• A yuno that relied on a persisted set=0 opens imposing again (the default is 1) until its configuration says false.

• Per treedb: dynamic_schema_treedbs (list, configuration, not persistent) names the treedbs that open from their schema file whatever impose_c_schema says, which stays the default of every other one: 'global': {'treedbs.dynamic_schema_treedbs': ['treedb_wattyzer']}. The yuno’s code still wins.

• New command treedbs in C_TREEDB: the treedbs the service opened (treedb_system_schema first), with impose_c_schema as it applies to each, decided_by (code, dynamic_schema_treedbs, impose_c_schema, system), and the literal, in-use and saved schema versions. Test 9b of c_treedb_system_schema covers both.

A treedb_schema_<db>.c is what the schema editor exports: the graph, then the literal¶

• treedb_schema_authzs.c, treedb_schema_mqtt_broker.c, treedb_schema_controlcenter.c, treedb_schema_yuneta_agent.c (and the docs-only treedb_schema_mqtt_subscriptions.c) hold the graph of the schema as a comment and the literal, nothing else: exactly what gobj-ui 7.25.1’s schema_to_c() exports, so an edit made in the GUI goes back into the source by replacing the file whole. The graph is derived (schema_to_diagram()), and replaces the hand-drawn ones; the notes those carried outside the schema are gone, except controlcenter’s planned lists / viewer_engines topics, kept in c_controlcenter.c beside their drafts. The broker’s alarm msg2db schema moves to its own modules/c/mqtt/src/msg2db_schema_alarms.c. No schema changed.

• New scripts/schema_diagram.mjs <file>...: rewrites the comment from the literal with the editor’s own code, after checking that the exporter reproduces that literal; --check exits 1 when a comment is stale.

• treedb_system_schema.c, the meta-schema, keeps its form.

v7.25.0 (2026-09-21)¶

C_TRANGER: a multi-key iterator holds no iterator per key (M22)¶

The memory half of M22 of the 2026-09-21 review.

• open-iterator rkey=... kept one full tranger2 iterator per matching key for the life of the iterator -- keys x files of memory, +147 MB for one whole-topic card over 1000 keys with 60 daily files, and gui_treedb reopened that card on every visit. It counts each key’s rows at open, keeps a number per key and the match conditions, and get-page opens only the keys its page touches, and closes them. Same answers, same total_rows, frozen at open as before. A filtered page rebuilds the index of the keys it reads.

• A topic closed and opened again still makes such an iterator “gone” (the A4 rule): the topic carries an epoch in memory, and the iterator is valid only on the opening it was made on. A deleted key is found by asking the topic, since no part iterator is there to be marked.

• gui_treedb 0.17.54: the whole-topic Rows card is no longer remembered and reopened on every visit; its options offer keys (regex), filled with .*; a new Rows card starts at from rowid = -100.

• Test: c_tranger (no tranger2 iterator held after the open, nor after a page; red against the previous library).

treedb: the fkey mark is derived, and no file carries it -- a hook can be renamed¶

M2 and M3 of the 2026-09-21 review.

• parse_hooks() marks each child fkey column with the one hook that fills it ("fkey": {parent_topic: hook}), and the loader keeps only the links it names. The mark was written to disk: parse_schema() marks the literal in place, and that literal is what the child’s topic_cols.json and the treedb schema file are written from. Renaming a hook raises only the PARENT’s topic_version, so the child reloaded the old mark -- “Only can be one fkey” at every open, and the links made through the new hook dropped at every restart.

• parse_hooks() clears every mark before it computes them, so a stale one read from a file of an older release is ignored; treedb_open_db() writes the schema file and the topics’ cols without it. In memory (and in descs) the mark is as it was.

• M3: a ref to a hook that no longer exists is stale. What a renamed or removed hook leaves in every child (departments^d1^users) hangs from nothing, and unlinking it failed on the missing hook (since 3fea635f3), so the child could be neither relinked, cleaned nor force-deleted. unlink_child_from_parent_ref() now removes such a ref from the child with a warning (“Parent ref names a hook that no longer exists”) and goes on. The children lose that parent: link them again through the new hook.

• Test: tr_treedb_hook_rename (red against the previous library on the error, the lost link, both files, and the clean and forced delete of a child that names the old hook).

C_TREEDB: an edit of a schema is a draft; save-schema publishes it, apply-schema puts it in use (BREAKING)¶

M36 of the 2026-09-21 review, the owner’s design. With gobj-ui 7.23.196 (the schema editor stops raising versions and marks drafts) and gui_agent 0.22.74 (Save, the imposed banner, and an Apply dialog with the relaunched yuno and the changes).

• The three commands take no treedb_name too: then they act on every treedb opened there with a schema from C and list the answers (apply-schema then applies only what can_apply), which is what a console holding a whole yuno sends.

• An edit of __system__ moves no version. Every write to a cols or topics node used to raise topic_version and schema_version (the “a write publishes itself” of M8), so an edit half made was already the schema of the next start. The writes are drafts now; publish_schema_change() is gone, and so is the __schema_publishing__ marker the projector set to keep it from answering its own writes.

• save-schema treedb_name=X [dry_run=1] publishes the draft: it compares it with the schema file IN USE (diff_treedb_schema(), the comparator of diff-schema), raises the topic_version of each topic that differs and the schema_version to the one in use + 1 (never lowering a number of __system__), writes them into __system__, and writes the schema to saved_schemas/X.treedb_schema.json under the __system__ tranger -- never over the file in use. The saved schema reads like a literal: empty attributes, _geometry and the projection’s bookkeeping versions are pruned, and topics is a list. Idempotent.

• saved-schema answers what was saved, a flat_diff against the file in use, impose_c_schema for that treedb (the code’s force included) and can_apply. apply-schema copies it over the file in use: master only, refused when C imposes the treedb’s schema, and only a higher schema_version. It takes effect at the next open.

• BREAKING: with impose_c_schema off a treedb opens from its schema FILE, not from __system__. The literal is handed to treedb_open_db() without impose, so it is installed only when it is newer; the file wins on ties and when it is ahead, which is what apply-schema makes it. __system__ is not read at open in either mode. Every in-tree yuno and every project’s db_history* forces impose_c_schema=1 from its code, so none of them changes behaviour: for them Save works and Apply is refused.

• Docs: YUNO_TREEDB.md (“A treedb never opens from __system__”, the three-step cycle with examples), the C_TREEDB page (the attribute and the three commands), and the C_NODE permission table, which still listed system-schema and trace as open to anyone (M41 closed that).

• Test: c_treedb_system_schema -- edits and creates/deletes are drafts, the whole save/saved/apply cycle (red against the previous library), and three checks rewritten on the new model; its expected log is a table now.

treedb: a now column is stamped by every write, writable or not¶

M5 of the 2026-09-21 review, the owner’s option B.

• 7.24.0 stamped a now column on an update only if it was writable, and its CHANGELOG said there were two now columns in the tree. There are about twenty more -- the “Update Time” of wattyzer, estadodelaire, hidraulia, yunovatios, the mqtt broker and treedb_authzs -- declared ['persistent','time','now'], with no writable: they stayed frozen at the create. now is stamped by EVERY write now, persistent or volatile; writable plays no part.

• The instant a thing was born is a time column without now. A create with no value gives it the clock and an update leaves it alone -- which is what __assets__.t (when the bytes arrived) needs, so it lost now (__assets__ topic_version 2). No new flag was needed: that is the only column in the tree that wants a birth time.

• A now column is an integer epoch; one of another type is not stamped (it used to be written as "" by every stamp). None exists in the tree.

• tr_treedb.h / lib_treedb.js: the comment of persistent says what the treedb does with it -- stored on disk, readable, NOT writable (unlike SDF_PERSIST of a gobj attribute, which implies SDF_WR).

• Test: tr_treedb_files case 19 (red against the previous library: a non-writable and a volatile now column stayed where the create put them).

treedb: a rowid id is not handed out again under an active snap¶

M4 of the 2026-09-21 review, the owner’s option A.

• The seed of the rowid counter read the treedb’s id index, which, with a snap active, holds only what the snap loaded. In a store with no last_rowid_id yet, a create without id got the id of a node created after the shot -- on disk, not in the index -- and exist_primary_node() asks the same index, so nothing refused it. The real case was __graphs__. The seed reads the keys of the topic, tranger2’s cache (every key on disk).

• treedb_activate_snap() returned the tag of the snap it REPLACED (0 when none was active), not the tag of the one it activated, as its header says. Callers only test < 0, so nothing broke; the result of C_NODE’s activate-snap carries the right tag now.

• Test: tr_treedb_rowid case 7 (red against the previous library: the create got 8, the id of the node the snap did not load).