refactor: make progress tracking better follow LSP semantics #260
Conversation
* Overhaul `Expert.Project.Progress` with a new progress reporting API. * Progress reporting only informs users of long-running work and doesn’t drive behavior. New interface accordingly KISS. * Removed releveant `__using__` macros in favor of simple `alias` + function calls. * Use plain tuples instead of `defrecord` for progress report messages between the server node and engine node. * Debounce namespace build logs to minimize spam.
* Store the manager node name on startup in the engine node. This fixes up some tests that were faltering due to the introduced rpc calls. This is more stable anyway, imo. * give project compilation more generous timeouts in testing (5s instead of 100ms)
Moosieus
changed the title
Moosieus
changed the title
Moosieus
changed the title
Moosieus
changed the title
mhanberg
changed the title
doorgan
left a comment
doorgan
left a comment
There was a problem hiding this comment.
I think this looks good, and from what I understand about the changes and from my testing it seems we're getting pretty much the same results with simpler code, so it's a +1 from me.
For my own understanding: we are moving from the engine node sending progress messages to the server to instead unifying everything under the new Progress API(so, we report progress directly to the LSP via erpc calls to the server, instead of sending progress to the server and having it create the messages). Is this correct?
| def with_tracked_progress(title, total, work_fn, report_fn) | ||
| when is_function(work_fn, 1) and is_function(report_fn, 4) do | ||
| run_with_progress(title, [percentage: 0], fn token -> | ||
| {:ok, tracker} = Tracker.start_link(token: token, total: total, report_fn: report_fn) |
There was a problem hiding this comment.
Should we use a DynamicSupervisor for this?
There was a problem hiding this comment.
I don't think it'd add much.
That's correct. Tried to make it as simple as can be w/o being simplistic. |
3 participants
This pull request overhauls the way progress reporting is handled in Expert. The top-level API remains largely the same for callers.
The prior architecture started a per-project stateful GenServer that handled progress tracking logic internally:
with_client_progressfunction incorporated here, but I removed it for the sake of review. There’s already a lot here.The new progress reporting modules are organized as follows:
Forge.Progress- a behaviour that defines thewith_progressandwith_tracked_progresshelper functions, permitting the implementing module provides the following functions:begin/2report/2complete/2Expert.Progress- a process-less module that directly handles progress reporting, implements the aforementionedEngine.Progress- a thin wrapper that callsExpert.Progressvia erpc.Forge.Progress.Tracker- An ephemeral GenServer for reporting progress between concurrently running tasks.turbo-encabulating files: 3/25should that be preferable.All in all: Less processes, more sequential Elixir, more flexibility, better alignment with LSP semantics.
Some additional changes:
project_compiledmessage less flaky by increasing the timeout from 100ms -> 5s.