Summary
It would be very helpful if LeafWiki exposed a manual way to trigger the same filesystem reconciliation/index refresh behavior that currently happens on startup, without requiring a full process/container restart.
Problem
In my setup, LeafWiki and another tool both interact with the same Markdown corpus on disk.
Right now, restarting the leafwiki container successfully causes LeafWiki to pick up external changes. That suggests the needed reconciliation already exists internally, but it appears to run only during app startup.
The operational problem is that using a container restart as the sync trigger creates a jarring UX:
- users can hit a temporary bad gateway or failed page load
- saves/redirects can race with the restart
- even a short restart is disruptive compared to an in-process refresh
What I would like
It would be very helpful if LeafWiki exposed an admin-triggerable filesystem reload/rescan endpoint that reruns the startup-time reconstruction logic without restarting the process.
Possible forms:
POST /api/admin/reload-from-fsPOST /api/admin/rescan- CLI subcommand like
leafwiki rescan --data-dir ...
- a signal-based reload hook, if that fits the architecture better
Expected behavior
When triggered, LeafWiki should:
- rescan/reconstruct the page tree from the filesystem
- refresh any derived metadata/indexes that startup normally rebuilds
- make newly changed external markdown visible without restarting the process
Why this would help
This would make LeafWiki much easier to integrate with external automation or neighboring tools that write markdown on disk.
It would also preserve availability and avoid the current “restart to resync” workaround.
My current use case: I currently watch for external sync completion and restart the container as a workaround. A soft reload endpoint would let me call that instead and avoid user-facing downtime.
Notes
From my inspection, the current startup path appears to do the needed work already, but there does not seem to be a public endpoint or command for it yet.
So this request is less about new sync logic and more about exposing the existing startup reconciliation path as a safe manual trigger.
If helpful, I’d be happy to test a proposed endpoint or CLI implementation.
Summary
It would be very helpful if LeafWiki exposed a manual way to trigger the same filesystem reconciliation/index refresh behavior that currently happens on startup, without requiring a full process/container restart.
Problem
In my setup, LeafWiki and another tool both interact with the same Markdown corpus on disk.
Right now, restarting the
leafwikicontainer successfully causes LeafWiki to pick up external changes. That suggests the needed reconciliation already exists internally, but it appears to run only during app startup.The operational problem is that using a container restart as the sync trigger creates a jarring UX:
What I would like
It would be very helpful if LeafWiki exposed an admin-triggerable filesystem reload/rescan endpoint that reruns the startup-time reconstruction logic without restarting the process.
Possible forms:
POST /api/admin/reload-from-fsPOST /api/admin/rescanleafwiki rescan --data-dir ...Expected behavior
When triggered, LeafWiki should:
Why this would help
This would make LeafWiki much easier to integrate with external automation or neighboring tools that write markdown on disk.
It would also preserve availability and avoid the current “restart to resync” workaround.
My current use case: I currently watch for external sync completion and restart the container as a workaround. A soft reload endpoint would let me call that instead and avoid user-facing downtime.
Notes
From my inspection, the current startup path appears to do the needed work already, but there does not seem to be a public endpoint or command for it yet.
So this request is less about new sync logic and more about exposing the existing startup reconciliation path as a safe manual trigger.
If helpful, I’d be happy to test a proposed endpoint or CLI implementation.