Memtrace v1.1.1

Memtrace v1.1.1

A watched repository is actually watched, and a running index says where it is

Fixed

• A repository watched by an editor session is now genuinely watched. Asking to watch a folder reported success and listed the path, but when Memtrace was serving an editor directly - rather than through a separate background service - no file save ever reached the graph. Saving a file produced nothing for as long as you waited, while asking for a re-index picked the same change up in seconds. Saves now reach the graph within seconds again in that mode.
• A running index reports the stage it is actually in. Progress was sent to the dashboard but not to the record that tools and assistants poll, so a large index looked frozen on the very first step from start to finish while the work proceeded normally underneath. Anything waiting for that record to move now sees it move.
• Clearing a repository while re-indexing it now says that its commit history has to be rebuilt. The clear removes that history along with everything else, but the result reported nothing outstanding, so the gap was invisible until a history query came back empty. Clearing is still not a safe refresh - remove the repository and index it again instead - and this at least stops the result from hiding it.
• A stalled internal lock can no longer block every write for as long as Memtrace keeps running. One lock could wait forever with no error and no way to see what it was waiting for; if that happened, re-indexing and cleanup stayed blocked and deleted code kept appearing in search until the process was restarted. It now gives up after a bounded wait and reports what it could not take.
• Connecting an editor session to an already-running Memtrace no longer refuses in one specific case where the running instance was healthy and had published everything correctly. This does not cover every report of that refusal - if yours persists, the message now names exactly what it looked for.

Install

npm install -g memtrace