Skip to content

v1.1.0

Choose a tag to compare

@github-actions github-actions released this 13 Sep 22:32
· 91 commits to main since this release

[1.1.0] — 2026-09-14

A directory is added to and removed from the index with a single edit to daemon.toml and serve.toml — without restarting the daemon or serve and without manual commands; clients' open MCP sessions are not dropped.

Added

  • Federation configuration is re-read on the fly. serve watches serve.toml and daemon.toml (one watch for both files, 500 ms debounce) and on an edit rebuilds the repository table as a whole: added aliases start being served, removed ones stop, and an entry whose path, address, port or language changed is updated. Previously serve.toml was read once at startup: a new alias required restarting serve, and a restart dropped the sessions of every connected client. The table is swapped in one step — sessions opened before the edit see the new set right away, and requests started before the swap finish on the previous one.
  • Manual POST /reload — the same mechanism on request, responding with {reloaded, generation, added, removed, changed, restart_required, error}. The route exists only in federation mode and is protected by the same allowed-address list.
  • The result of the last re-read in the health tool — the config_reload field.
  • The daemon watches daemon.toml itself (500 ms debounce, read events on Linux are dropped by the same filter serve uses) and applies added and removed directories. The daemon reload command remains as a manual fallback.
  • A removed directory stops being tracked without restarting the daemon. Previously a re-read only added directories, while the watch task of a removed one kept running and writing to its database until a restart. Now each task has its own stop signal: it finishes cleanly — between files, parse portions and transactions, never cutting a write short; the watchdog does not respawn it; the directory's files and database stay on disk. If the directory is added back, the new task starts only after the previous one has finished.

How an edit is applied

  • All or nothing. The new table is fully built before the swap. If either file fails to parse, a new repository's database fails to open, or its directory does not exist, nothing changes: the previous table stays and the reason is in error. No directories are created during a re-read.
  • The pair of files is cross-checked. A local alias in serve.toml without an entry in daemon.toml is not applied: while only one file has been edited, the previous table stays. An intermediate state between two saves never publishes a truncated set.
  • Open databases are reused. For unchanged local repositories the connection pool is not reopened; a new repository's database is created when needed, the same way as at startup.
  • Response cache and repeat suppression. For removed and changed aliases the cache is cleared before and after the swap, so a request crossing the swap cannot put back a stale response; repeat suppression is reset.
  • The allowed-address list is updated together with the table: at the moment of the swap the union of the old and new sets applies, then exactly the new one.
  • Restart only: a [me].ip change is not applied at all (restart_required: ["[me].ip"]); a [pool] change is reported in restart_required, and new databases open with the previously applied pool settings. The tool list, mass mode and response limits from daemon.toml are still read at startup. Mode without serve.toml is unchanged.
  • Stopping a daemon task. Initial indexing in the daemon runs in portions of batch_size files so a stop takes effect between them; an unfinished indexing is marked in the database and completed the next time the directory is added. A full 1C extension build cannot be interrupted safely — the stop waits for it to finish (minutes on a large configuration). If the same directory is added back during that time, the daemon refuses to start a second task after 5 s and logs the reason — save the file again or run daemon reload later.

Verification

  • Unit and integration tests: cargo test --workspace --all-targets — 848 passed, 0 failed; with --features enrichment — 857 passed, 0 failed; no compiler warnings. 24 new tests: swapping the table and the address list is visible to an already open session; an entry taken before an alias is removed keeps working; re-read — adding a remote and a local alias, an alias without a pair, a parse error and a missing file for each of the two, pool reuse, removal, [me].ip and [pool] changes, a non-existent root, selective cache clearing, a repeat with no changes, concurrent re-reads; the watcher filter for two files; daemon — its own signal stops a task, removing a directory moves the task to stopping and the watchdog does not respawn it, adding it back waits for the previous task and starts exactly one, a full pass stops before writing, a daemon.toml parse error leaves the directory set unchanged, the daemon watcher filter.
  • Locally, live serve under the supervisor, one MCP session for the whole scenario: a repository added to both files was applied by the watcher within a second — database created, the same session found a function in the new repository; an alias only in serve.toml was rejected with the reason, the table unchanged; after the files were restored the alias was gone, neighbouring repositories answer, and the session stayed alive to the end. A separate scenario using only edits to the two files, with no command at all: the daemon picked up the directory and made it ready within 2 s, serve added the alias; after removal from the files the daemon stopped tracking the directory — an edit to a file in it never reached the database; adding it back picked up a function written in between; deleting the directory from disk caused no errors; the daemon and serve PIDs did not change.
  • Federation: the node (Linux, Docker) was rebuilt on this build — the file checksum in both containers matched the built one. Remote repositories answer through the local serve, including an extension tool. On the node the same scenario as locally: a directory added to daemon.toml and serve.toml started being served without restarting serve, the same session found a function in it, an alias without a pair was rejected, and after the files were restored the directory was gone; a remote alias appended to serve.toml was applied by the watcher within a second; no repeated re-reads within 20 s — read events on Linux do not cause a loop; POST /reload from another machine on the network returns 200; the node configuration was restored. The daemon scenario on the node, file edits only: the directory was ready within 3 s, after removal it was no longer tracked or indexed, adding it back picked up the new function, deleting it from disk caused no errors; the start time of both containers did not change; the daemon log shows only real daemon.toml applications, with no repeats from read events.

Russian version of the changelog: CHANGELOG.md.

Full Changelog: v1.0.5...v1.1.0