Open taelfrinn opened 6 years ago
logging in general seems extremely sparse. It might be worthwhile for noteable .catch paths in the core logic to make log file entries.
It also seems like much of the code is happy-path-only contaigious. (If one part fails, it spreads and causes other unrelated things to fail also) For example: whenever git remote push fails, image thumbnail loading also fails.
Thanks for the response!
jobs.push(global.git.resync().then(() => klaw
so it specifically bails on indexing when there is trouble with git sync. I think that explains it
I suppose the intention is to not attempt to crawl the directory while a git sync in in progress; that said git sync errors could catch, report, and resolve without preventing reindexing.
let bgAgent = fork(path.join(SERVERPATH, 'agent.js'))
Its interesting that this is done in a child process; being that node is already an event loop im curious why that would be beneficial (fd limits?)
Thanks again :)
..and when a page is(re)edited - then it is this page part of the index. Other pages not. I have exact the same problem - but it seems that not any git sync is in process. I use a local installed git-core at the docker host engine.
-> You can verfify the issue, when You disable git sync with
git: false
in config.yml
Then should the search work fine after a restart - and the issue is scoped to the git sync.
Search index empty on each wiki start
Expected: search not empty
Make a new new wiki using docker, view the "all pages" index, create a new page, see it is added, restart wiki, see no pages listed.
At the very least I would like to request a pointer at which code or logic would rebuild the index from scratch. From what I see in the code it looks like it is only ever stored in ram and thus ephemeral. Also, I see no code to rebuild it.
To fix this I suppose a promise coroutine that iterates all pages ad add's them to the index could help. Also, the index could be stored in mongo perhaps, rathen than being in ram.