Overview - Nx

NxWorkspace

CI Pipeline Executions
- Filtered
Runs
Demo

Insights

Compare tasks
Analytics

Sign in

Overview

Nx

Loading workspace stats

Loading workspace insights...

Statistics interval

7 days30 days

Latest CI Pipeline Executions

Filter

Fuzzy

Sort by

© 2026 - Nx Cloud

Terms of Service Privacy Policy Changelog Status Docs Contact Nx Cloud Pricing Company @NxDevTools

NxWorkspace

Agents
Replay
VCS
Self-Healing

Average execution time

30m 57s

1072 CI pipeline executions

Computation time saved

243d 10h

Cache hit rate

59%

Time to Green

4h 8m

Was 15h 54m, improved by 74%

Succeeded
36999
b97bca0c cleanup(core): rename plugin capabilities
by Jason Jean
J
Canceled
36999
bc6a08c6 cleanup(core): rename plugin capabilities
by Jason Jean
J
Failed
36999
5628ea1a cleanup(core): rename plugin capabilities
by Jason Jean
J
Failed
36999
Fix ready→
44003fbe cleanup(core): rename plugin capabilities
by Jason Jean
J
Canceled
36999
0704acba cleanup(core): cover loading plugins when nothing records their capabilities
by FrozenPandaz
Canceled
36999
0704acba cleanup(core): cover loading plugins when nothing records their capabilities
by FrozenPandaz
Canceled
36999
b3b99c70 cleanup(core): require computedAt when writing the project graph cache
by FrozenPandaz
Canceled
36999
5e8ce65b cleanup(core): return computedAt from readProjectGraphCache
by FrozenPandaz
Canceled
36999
5e8ce65b cleanup(core): return computedAt from readProjectGraphCache
by FrozenPandaz
Canceled
36999
5e8ce65b cleanup(core): return computedAt from readProjectGraphCache
by FrozenPandaz
Canceled
36999
5e8ce65b cleanup(core): return computedAt from readProjectGraphCache
by FrozenPandaz
Canceled
36999
5e8ce65b cleanup(core): return computedAt from readProjectGraphCache
by FrozenPandaz
Canceled
36999
e77a10c7 cleanup(core): drop the per-plugin capability records The graph's own build now records what its plugins register, so the per-plugin records, their freshness checks, the capability lock and the load observation behind them are no longer needed.
by FrozenPandaz
Failed
36999
5e7c0064 fix(core): follow the root tsconfig's extends chain on a plugin record Resolution reads `customConditions` through TypeScript, so a condition inherited from a config the root tsconfig extends steers it as much as one set in the root file, and only the root file was on the record. `readTsConfigInputs` runs the existing `readTsConfig` with a `ts.System` that notes what it reads, so the chain is whatever TypeScript itself resolved, configs extended from a package included, rather than a second walker's idea of it.
by FrozenPandaz
Failed
36999
6615eded fix(core): key a local plugin on what nx.json names it Keying it on where it resolves meant resolving it, and resolving a plugin that is not an installed package reads every project configuration: 1.2s in this repository, against the 100-500ms plugin load the record exists to save. A client would not pay that, so it declined to key such a plugin at all, and one local plugin among five installed ones sent the whole answer back to loading every one of them. The name is enough, because the key never carried freshness: the record holds the files the load read, so a name that starts resolving elsewhere fails its hash and is loaded again. Keying before resolution takes 0.4ms, and both sides agree on the key, which is what lets a client find what the daemon recorded. This is what the workspace-walk guard existed to avoid, so that goes.
by FrozenPandaz
Canceled
36999
6615eded fix(core): key a local plugin on what nx.json names it Keying it on where it resolves meant resolving it, and resolving a plugin that is not an installed package reads every project configuration: 1.2s in this repository, against the 100-500ms plugin load the record exists to save. A client would not pay that, so it declined to key such a plugin at all, and one local plugin among five installed ones sent the whole answer back to loading every one of them. The name is enough, because the key never carried freshness: the record holds the files the load read, so a name that starts resolving elsewhere fails its hash and is loaded again. Keying before resolution takes 0.4ms, and both sides agree on the key, which is what lets a client find what the daemon recorded. This is what the workspace-walk guard existed to avoid, so that goes.
by FrozenPandaz
Succeeded
36999
85d093f1 fix(core): let one code mean a lock timed out The fallback status was a second code meaning the same thing, so the guard had to accept both and a napi `Cancelled` from anywhere else read as a timeout. Where the error object cannot be built the rejection is an ordinary failure carrying the same message, and `code: 'Timeout'` is the only thing a caller treats as the budget running out.
by FrozenPandaz
Canceled
36999
85d093f1 fix(core): let one code mean a lock timed out The fallback status was a second code meaning the same thing, so the guard had to accept both and a napi `Cancelled` from anywhere else read as a timeout. Where the error object cannot be built the rejection is an ordinary failure carrying the same message, and `code: 'Timeout'` is the only thing a caller treats as the budget running out.
by FrozenPandaz
Canceled
36999
11e157f9 fix(core): reject a lock wait that never came free, and answer the review The wait returned a boolean nobody had to read, which is how this PR's first version read a graph cache its holder had never written. It resolves once the lock is free — whether it was free all along or the holder let go — and rejects with napi's `Cancelled` when the budget runs out, so a timeout cannot be stepped past. A filesystem failure still rejects as itself, which the graph lock propagates and the capability lock now degrades past rather than failing a load over a cache it can do without. The graph-lock loop had two branches doing the same thing on a timeout; now it has one. Carried in the same files, from a review of the previous commits: - Clearing the peek memo on a repair was not enough on its own: a peek assigns it several awaits after reading the records, so a correction landing in between was undone by the answer that predates it. A generation counter makes the late assignment drop itself. - `cleanupPlugins` resets the load queue, which otherwise holds later callers behind a turn nobody is waiting on. - The env filter also excludes the settings the daemon pins on itself, which are set in a daemon worker and unset in a daemonless one. - A resolution asked for without the workspace walk no longer declines when the walk has already happened in this process. - Three comments said what the code no longer does: the wait taking a libuv worker, the loaders loading together rather than in turn, and the peek loading and recording on a client that now leaves both to its daemon.
by FrozenPandaz
Canceled
36999
11e157f9 fix(core): reject a lock wait that never came free, and answer the review The wait returned a boolean nobody had to read, which is how this PR's first version read a graph cache its holder had never written. It resolves once the lock is free — whether it was free all along or the holder let go — and rejects with napi's `Cancelled` when the budget runs out, so a timeout cannot be stepped past. A filesystem failure still rejects as itself, which the graph lock propagates and the capability lock now degrades past rather than failing a load over a cache it can do without. The graph-lock loop had two branches doing the same thing on a timeout; now it has one. Carried in the same files, from a review of the previous commits: - Clearing the peek memo on a repair was not enough on its own: a peek assigns it several awaits after reading the records, so a correction landing in between was undone by the answer that predates it. A generation counter makes the late assignment drop itself. - `cleanupPlugins` resets the load queue, which otherwise holds later callers behind a turn nobody is waiting on. - The env filter also excludes the settings the daemon pins on itself, which are set in a daemon worker and unset in a daemonless one. - A resolution asked for without the workspace walk no longer declines when the walk has already happened in this process. - Three comments said what the code no longer does: the wait taking a libuv worker, the loaders loading together rather than in turn, and the peek loading and recording on a client that now leaves both to its daemon.
by FrozenPandaz