Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
35342
f64e9e80 fix(core): code review feedback
by Craigory C...
Succeeded
35342
8a1c4ba7 fix(core): code review feedback
by Craigory C...
Canceled
35342
f3405d98 chore(core): tidy streaming helpers and per-request spinner plumbing Addresses review feedback on #35342: - writeStreamingMessage now mirrors the logging shape of respondToClient in shutdown-utils (broadcast / done / error lines via serverLogger, with the message type as the description). - Move the broadcast-to-subscribers implementation into client-socket-context as sendLogToTopic; DaemonLogger#logToClient now orchestrates it and falls back to the daemon log only when nobody is subscribed. - sendProgressMessageToTopic and sendLogToTopic go through the exported getTopicSubscribers helper rather than peeking at the internal map directly. - Rename the sendToDaemonViaQueue option from `force` to `parser` for clarity and drop the spinner plumbing from it. The caller (getProjectGraphAndSourceMaps) now sets `this.currentSpinner` directly and clears it in a finally block. - isolated-plugin.ts and worker-streaming.ts fall back to `console[level]()` for log notifications instead of raw process.stdout/stderr writes, keeping parity with how the daemon client renders emit-log messages. https://claude.ai/code/session_014sDuF5eLunmQPHsRRWLTMo
by Claude
Succeeded
35342
7cc774d9 fix(core): route daemon streaming progress through per-request spinner The client previously mutated the process-wide globalSpinner on every incoming progress message, which could overwrite the text of an unrelated command that had started its own spinner. Since the daemon client is a serialized message queue, carry the owning spinner alongside the in-flight request via a new currentSpinner field (set inside the queued function and cleared in a finally). handleMessage now drives that spinner directly, so streamed updates never reach anyone else's UI. https://claude.ai/code
by Craigory C...
Canceled
35342
7cc774d9 fix(core): route daemon streaming progress through per-request spinner The client previously mutated the process-wide globalSpinner on every incoming progress message, which could overwrite the text of an unrelated command that had started its own spinner. Since the daemon client is a serialized message queue, carry the owning spinner alongside the in-flight request via a new currentSpinner field (set inside the queued function and cleared in a finally). handleMessage now drives that spinner directly, so streamed updates never reach anyone else's UI. https://claude.ai/code
by Craigory C...
Canceled
35342
7d19437e fix(core): stop subscribing HASH_TASKS to graph-construction progress The client does not render hashing progress (handleMessage ignores streaming messages outside of REQUEST_PROJECT_GRAPH), so subscribing the hash path was pure coupling and wasted socket traffic. Revert handleHashTasks to its socket-less signature. https://claude.ai/code
by Craigory C...
Canceled
35342
201e12a7 chore(core): extract ProgressTopics into utils/progress-topics The topic constant is the contract between progress producers (DelayedSpinner callers) and the daemon subscriber registry, so it belongs next to the spinner rather than inside the daemon's client-socket bookkeeping. Also sidesteps a latent import cycle between delayed-spinner.ts and the daemon server module. https://claude.ai/code
by Craigory C...
Canceled
35342
a7bab9e6 feat(core): route daemon streaming progress through named topics Replace the AsyncLocalStorage single-socket progress model with a topic-based subscriber registry. Long-running daemon operations register subscribers for a named topic on entry and unregister on exit; broadcast helpers fan out to every currently-subscribed socket. - Introduces ProgressTopics.GraphConstruction as the first (and only) topic today. Add more as other daemon operations grow their own streaming surfaces. - getCachedSerializedProjectGraphPromise now takes the requesting socket and subscribes it to GraphConstruction for the duration of the await. Clients that join a recomputation already in flight now receive the remaining progress messages — previously only the client that initiated the compute got them, and file-watcher-triggered recomputations produced no notifications at all. - DelayedSpinner accepts an optional progressTopic option; when set and running inside the daemon, every setMessage broadcasts to that topic's subscribers. - DaemonLogger#logToClient now takes a topic and falls back to the daemon log when no clients are subscribed. https://claude.ai/code
by Craigory C...
Canceled
35342
0c31a668 refactor(core): relocate streaming helpers per review feedback Addresses a second round of review feedback on #35342: - emitLogToClient is now a method on DaemonLogger (serverLogger.emitToClient) so daemon-to-client log forwarding lives alongside the rest of the daemon logging surface. - Progress forwarding moves into DelayedSpinner itself rather than living at the call site. Any caller that uses DelayedSpinner inside the daemon now automatically streams progress to the client — this picks up createDependencies and createMetadata for free. project-configuration-utils.ts is reverted to its original shape. - writeStreamingMessage uses the shared serialize() helper with v8 handling instead of a bespoke JSON.stringify call. - getActiveClientSocket is used across files, kept as a small named export rather than inlined. - emit-log notifications from plugin workers now fall back to stdout/stderr when no host socket is connected, so they aren't silently dropped when plugin isolation is off. - Drop the unused plugin-worker updateProgress notification path and accompanying types — there's no caller for it yet. - Remove an unnecessary eslint-disable on a console[level] call that isn't actually disallowed. https://claude.ai/code/session_014sDuF5eLunmQPHsRRWLTMo
by Claude
Succeeded
35342
a598127c refactor(core): tighten streaming helpers to daemon-only Addresses review feedback on #35342: - sendProgressMessageToClient and emitLogToClient now throw when called outside of the Nx daemon process, making misuse loud rather than silent. - createProjectConfigurationsWithPlugins gates the progress forwarding behind isOnDaemon() so the helpers are never reached in the direct CLI case. - Reverts the emit-log use of the cache-write failure warning — that warning is fine staying in the daemon log. https://claude.ai/code/session_014sDuF5eLunmQPHsRRWLTMo
by Claude
Canceled
35342
b12a4565 feat(core): surface plugin progress and cache warnings from daemon Wires up the first two real uses of the streaming message channel: - createProjectConfigurationsWithPlugins now sends its in-flight spinner text through sendProgressMessageToClient. Under the daemon the local spinner is a no-op, so this makes the client-side spinner reflect which plugin is still running (e.g. "Creating project graph nodes with @nx/jest") rather than the generic "Calculating the project graph on the Nx Daemon" message. - The graph cache-write failure warning in writeCache is routed to emitLogToClient when running on the daemon. Previously the warning landed only in the daemon log and users never saw it. https://claude.ai/code/session_014sDuF5eLunmQPHsRRWLTMo
by Claude