Repository navigation
v1.1.0
[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.
servewatchesserve.tomlanddaemon.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. Previouslyserve.tomlwas 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
healthtool — theconfig_reloadfield. - The daemon watches
daemon.tomlitself (500 ms debounce, read events on Linux are dropped by the same filter serve uses) and applies added and removed directories. Thedaemon reloadcommand 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.tomlwithout an entry indaemon.tomlis 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].ipchange is not applied at all (restart_required: ["[me].ip"]); a[pool]change is reported inrestart_required, and new databases open with the previously applied pool settings. The tool list, mass mode and response limits fromdaemon.tomlare still read at startup. Mode withoutserve.tomlis unchanged. - Stopping a daemon task. Initial indexing in the daemon runs in portions of
batch_sizefiles 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 rundaemon reloadlater.
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].ipand[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, adaemon.tomlparse 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.tomlwas 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.tomlandserve.tomlstarted 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 toserve.tomlwas applied by the watcher within a second; no repeated re-reads within 20 s — read events on Linux do not cause a loop;POST /reloadfrom 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 realdaemon.tomlapplications, with no repeats from read events.
Russian version of the changelog: CHANGELOG.md.
Full Changelog: v1.0.5...v1.1.0