Compute signatures of dependent files in parallel on incremental rebuilds by resure · Pull Request #64659 · microsoft/TypeScript

Gadzhi Gadzhiev (resure) · 2026-10-06T20:42:32Z

After an edit to a widely imported file, the incremental builder computes the declaration signature of every file that references it, to find what is affected. It did that one file at a time, so this phase ran on about one core. Each referencing file is now its own task in the existing work group.

This is the second half of #64469 (for #64464), which removed the checker scan that took most of the time.

Most of this change was generated with AI tooling; I have hit this problem myself and have reviewed the result.

The 6,000-leaf reproducer from #64464, first rebuild after a comment-only edit to hub.ts with noEmit and incremental. 32-core Linux, median of 5 runs, main already includes #64469.

	wall time	CPU	peak RSS
main	3.4 s	206%	368 MiB
this PR	1.5 s	524%	370 MiB

The tsbuildinfo after the rebuild is byte-identical to main's. The gain is smaller on a real project: on n8n's packages/nodes-base the same kind of edit to a file that 433 files reference goes from 5.4 s to 4.5 s, and an edit to its most referenced file takes about 2.5 s either way.

Signatures in flight are capped at GOMAXPROCS to keep memory down: after an edit to all 6,000 leaves the rebuild peaks at 377 MiB against 456 MiB on main, in the same 1.5 s. The cap lives in the work group. core.NewWorkGroup now takes a concurrency instead of singleThreaded (0 = unlimited), which is why so many call sites change. The existing ones pass 1 or 0 and behave as before, only the two groups in collectAllAffectedFiles get a cap. It is per group, so tsc -b building several projects at once can exceed it in total. main has no cap there at all.

The speedup also depends on the number of checkers, since a signature needs its file's checker. The default is four, and with --checkers 8 the rebuild takes 1.2 s. There is nothing to gain under isolatedModules, where referencing files are not walked.

Separately, updateShapeSignature returned false when another traversal had already computed the file's signature. It now returns whether the signature changed. On main the old answer makes the result depend on which changed file is processed first: in a case like the one in TestUpdateShapeSignatureCachedResult, with --singleThreaded 20 of 40 runs wrote a different tsbuildinfo than the rest, and with assumeChangesOnlyAffectDirectDependencies 23 of 40 missed the resulting error. This does not depend on the parallelism, so I can split it out if that is easier to review.

After a shared dependency changes, the incremental builder computed the declaration signatures of the files referencing it one at a time. Each referencing file now gets its own task in the work group, with at most GOMAXPROCS signatures in flight so peak memory stays where it was. The cached path of updateShapeSignature returned false when another traversal had already computed the file's signature, which made the result depend on which changed file was processed first: a changed file that affects the global scope could fail to invalidate every file. It now reports whether that signature changed.

typescript-automation · 2026-10-06T20:42:38Z

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

Copilot

Copilot review overview

🟡 Changes recommended

Root changed-file signature computations bypass the new concurrency limit, allowing unbounded concurrent declaration emits.

Review effort: Balanced
Findings: 1

Open (1)

Changed-file signature computations bypass concurrency semaphore · New

What changed in this PR

Parallelizes incremental declaration-signature computation while preserving deterministic invalidation behavior.

Changes:

Queues dependent signature computations concurrently with deduplication.
Corrects cached signature-change reporting.
Adds regression tests, baselines, and a performance benchmark.

File	Description
`tsc/internal/execute/incremental/affectedfileshandler.go`	Implements parallel signature traversal and caching changes.
`tsc/internal/execute/incremental/affectedfileshandler_test.go`	Adds an incremental rebuild benchmark.
`tsc/internal/execute/incremental/affectedfileshandler_internal_test.go`	Tests cached signature-change behavior.
`tsc/internal/execute/tsctests/tsc_test.go`	Adds incremental and watch regression scenarios.
`tsc/testdata/baselines/reference/tsc/incremental/shared-dependency-with-inferred-types.js`	Records incremental compiler output.
`tsc/testdata/baselines/reference/tscWatch/incremental/shared-dependency-with-inferred-types.js`	Records watch-mode output.

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

The limit only covered files reached through references, so a rebuild with many directly changed files still started all of their declaration emits at once. Take the semaphore inside computeDtsSignature instead.

Copilot

Copilot review overview

🔵 Needs a closer look

The concurrency-sensitive compiler traversal warrants final human review despite comprehensive regression coverage.

Review effort: Balanced
Findings: None

Resolved since last review (1)

Changed-file signature computations bypass concurrency semaphore

Wesley Wigham (weswigham)

It's cute to use the existing workgroup for this - but actually, if we need to limit parallelism for performance, why not limit the original workgroup size instead of taking a semaphore for just this path? Feels like we should be able to swap the singleThreaded parameter to a concurrency parameter that takes a max-parallel-threads count (0=infinity, I suppose) and do the limiting in the core concurrency construct.

…e-computation

Gadzhi Gadzhiev (resure) · 2026-10-08T19:05:44Z

Makes sense, done in 7f0e5e1. NewWorkGroup now takes concurrency instead of singleThreaded (0 = unlimited) and the semaphore is gone. Only the two groups in collectAllAffectedFiles get a limit (GOMAXPROCS), the rest pass 1 or 0, so nothing changes for them.

The limit is per group now, not process-wide, so with tsc -b building several projects at once there can be more than GOMAXPROCS signatures running in total. main has no limit there at all, so I left it that way.

Time and memory on the reproducer are the same as with the semaphore, about 1.5 s and 375 MiB.

Wesley Wigham (weswigham)

I think this looks good, but Andrew Branch (@andrewbranch) should also take a look.

We also don't actually have a benchmark that this inherently helps with, but I will throw out a
TypeScript Bot (@typescript-bot) test this
just in case.

typescript-automation · 2026-10-19T16:42:30Z

Starting jobs; this comment will be updated as builds start and complete.

Command	Status	Results
`test top400`	✅ Started	✅ Results
`user test this`	✅ Started	✅ Results
`run dt`	✅ Started	✅ Results
`perf test this faster`	✅ Started	👀 Results

typescript-automation · 2026-10-19T17:11:34Z

Hey Wesley Wigham (@weswigham), the results of running the DT tests are ready.

Everything looks the same!

You can check the log here.

typescript-automation · 2026-10-19T17:15:40Z

Wesley Wigham (@weswigham)
The results of the perf run you requested are in!

Here they are:

tsc

Comparison Report - baseline..pr

_Metric	_baseline	_pr	_Delta	_Best	_Worst	_p-value
_{Compiler-Unions - native}
_Errors	₄₁	₄₁	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_115,276	_115,276	_~	_~	_~	_{p=1.000 n=12}
_Types	_79,613	_79,613	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{113,525k (± 0.07%)}	_{113,479k (± 0.04%)}	_~	_113,337k	_113,590k	_{p=0.843 n=12}
_{Memory Allocs}	_{2,212,520 (± 0.00%)}	_{2,212,547 (± 0.01%)}	_~	_2,212,350	_2,212,986	_{p=0.843 n=12}
_{Config Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Parse Time}	_{0.049s (± 3.36%)}	_{0.049s (± 2.29%)}	_~	_0.046s	_0.051s	_{p=0.309 n=12}
_{Bind Time}	_{0.018s (± 9.45%)}	_{0.016s (± 9.27%)}	_{🟩-0.003s (-15.32%)}	_0.014s	_0.021s	_{p=0.015 n=12}
_{Check Time}	_{0.564s (± 0.71%)}	_{0.564s (± 0.63%)}	_~	_0.554s	_0.576s	_{p=0.680 n=12}
_{Emit Time}	_{0.330s (± 3.21%)}	_{0.325s (± 3.35%)}	_~	_0.298s	_0.350s	_{p=0.599 n=12}
_{Total Time}	_{0.969s (± 1.22%)}	_{0.962s (± 1.01%)}	_~	_0.936s	_0.988s	_{p=0.523 n=12}
_{angular-1 - native}
_Errors	₃	₃	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_{847,238 (± 0.05%)}	_{847,176 (± 0.08%)}	_~	_844,995	_848,588	_{p=1.000 n=12}
_Types	_{247,033 (± 0.00%)}	_{247,032 (± 0.00%)}	_~	_247,030	_247,042	_{p=0.491 n=12}
_{Memory Used}	_{596,416k (± 0.03%)}	_{596,366k (± 0.02%)}	_~	_596,067k	_596,665k	_{p=0.713 n=12}
_{Memory Allocs}	_{13,150,823 (± 0.18%)}	_{13,141,003 (± 0.03%)}	_~	_13,135,745	_13,157,472	_{p=0.887 n=12}
_{Config Time}	_{0.017s (± 1.70%)}	_{0.017s (± 1.70%)}	_~	_0.016s	_0.017s	_{p=1.000 n=12}
_{Parse Time}	_{0.223s (± 2.95%)}	_{0.225s (± 2.28%)}	_~	_0.212s	_0.239s	_{p=0.434 n=12}
_{Bind Time}	_{0.081s (±12.07%)}	_{0.077s (±14.06%)}	_~	_0.060s	_0.115s	_{p=0.354 n=12}
_{Check Time}	_0s	_0s	_~	_~	_~	_{p=1.000 n=12}
_{Emit Time}	_{1.555s (± 1.57%)}	_{1.551s (± 1.39%)}	_~	_1.495s	_1.617s	_{p=0.899 n=12}
_{Total Time}	_{1.896s (± 1.69%)}	_{1.888s (± 1.43%)}	_~	_1.819s	_1.956s	_{p=0.561 n=12}
_{mui-docs - native}
_Errors	_11,405	_11,405	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_4,331,983	_4,331,983	_~	_~	_~	_{p=1.000 n=12}
_Types	_1,370,520	_1,370,520	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{2,626,229k (± 0.05%)}	_{2,625,108k (± 0.06%)}	_~	_2,621,913k	_2,629,965k	_{p=0.143 n=12}
_{Memory Allocs}	_{27,707,410 (± 0.04%)}	_{27,722,147 (± 0.12%)}	_~	_27,656,505	_27,827,028	_{p=0.713 n=12}
_{Config Time}	_{0.017s (± 1.45%)}	_{0.017s (± 1.45%)}	_~	_0.016s	_0.017s	_{p=1.000 n=12}
_{Parse Time}	_{0.480s (± 1.80%)}	_{0.482s (± 2.15%)}	_~	_0.459s	_0.519s	_{p=1.000 n=12}
_{Bind Time}	_0.002s	_0.002s	_~	_~	_~	_{p=1.000 n=12}
_{Check Time}	_{7.265s (± 0.76%)}	_{7.255s (± 0.44%)}	_~	_7.199s	_7.342s	_{p=0.943 n=12}
_{Emit Time}	_{0.512s (±12.96%)}	_{0.511s (±11.39%)}	_~	_0.416s	_0.658s	_{p=0.766 n=12}
_{Total Time}	_{9.036s (± 0.47%)}	_{8.992s (± 0.91%)}	_~	_8.733s	_9.145s	_{p=0.478 n=12}
_{strada-build-src - native}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_1,388,680	_1,388,680	_~	_~	_~	_{p=1.000 n=12}
_Types	_441,862	_441,862	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{1,315,836k (± 0.74%)}	_{1,314,643k (± 0.40%)}	_~	_1,303,370k	_1,333,004k	_{p=0.671 n=12}
_{Memory Allocs}	_{78,192,522 (± 0.16%)}	_{78,177,318 (± 0.15%)}	_~	_77,816,744	_78,382,650	_{p=0.799 n=12}
_{Config Time}	_{0.004s (±11.30%)}	_{0.004s (±12.82%)}	_~	_0.003s	_0.006s	_{p=0.742 n=12}
_{Parse Time}	_{0.308s (± 2.33%)}	_{0.306s (± 2.13%)}	_~	_0.296s	_0.328s	_{p=0.660 n=12}
_{Bind Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Check Time}	_{2.003s (± 0.33%)}	_{2.012s (± 0.55%)}	_~	_1.980s	_2.044s	_{p=0.325 n=12}
_{Emit Time}	_{0.355s (± 3.95%)}	_{0.361s (± 3.97%)}	_~	_0.325s	_0.400s	_{p=0.723 n=12}
_{Total Time}	_{23.804s (± 0.56%)}	_{23.963s (± 0.36%)}	_{+0.159s (+ 0.67%)}	_23.669s	_24.169s	_{p=0.023 n=12}
_{strada-compiler - native}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_334,953	_334,953	_~	_~	_~	_{p=1.000 n=12}
_Types	_197,616	_197,616	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{247,555k (± 0.03%)}	_{247,529k (± 0.03%)}	_~	_247,408k	_247,702k	_{p=0.619 n=12}
_{Memory Allocs}	_{4,329,973 (± 0.01%)}	_{4,329,666 (± 0.01%)}	_~	_4,328,355	_4,331,098	_{p=0.242 n=12}
_{Config Time}	_0.001s	_0.001s	_~	_~	_~	_{p=1.000 n=12}
_{Parse Time}	_{0.114s (± 4.39%)}	_{0.113s (± 4.78%)}	_~	_0.101s	_0.128s	_{p=0.854 n=12}
_{Bind Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Check Time}	_{0.963s (± 0.52%)}	_{0.959s (± 0.43%)}	_~	_0.948s	_0.972s	_{p=0.223 n=12}
_{Emit Time}	_{0.150s (± 7.27%)}	_{0.152s (± 4.61%)}	_~	_0.132s	_0.171s	_{p=0.723 n=12}
_{Total Time}	_{1.284s (± 0.95%)}	_{1.280s (± 0.89%)}	_~	_1.248s	_1.305s	_{p=0.600 n=12}
_{ts-pre-modules - native}
_Errors	₈₇	₈₇	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_303,834	_303,834	_~	_~	_~	_{p=1.000 n=12}
_Types	_181,663	_181,663	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{215,230k (± 0.03%)}	_{215,258k (± 0.02%)}	_~	_215,192k	_215,374k	_{p=0.876 n=12}
_{Memory Allocs}	_{1,401,651 (± 0.02%)}	_{1,401,529 (± 0.02%)}	_~	_1,400,816	_1,402,241	_{p=0.843 n=12}
_{Config Time}	_0.000s	_{0.000s (±217.90%)}	_~	_0.000s	_0.001s	_{p=1.000 n=12}
_{Parse Time}	_{0.096s (± 2.93%)}	_{0.096s (± 3.53%)}	_~	_0.089s	_0.106s	_{p=0.853 n=12}
_{Bind Time}	_{0.039s (± 9.01%)}	_{0.041s (± 9.15%)}	_~	_0.031s	_0.050s	_{p=0.578 n=12}
_{Check Time}	_{0.741s (± 0.63%)}	_{0.740s (± 0.64%)}	_~	_0.733s	_0.753s	_{p=0.920 n=12}
_{Emit Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Total Time}	_{0.892s (± 0.30%)}	_{0.892s (± 0.58%)}	_~	_0.880s	_0.903s	_{p=0.598 n=12}
_{vscode - native}
_Errors	₃₉₆	₃₉₆	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_12,420,498	_12,420,498	_~	_~	_~	_{p=1.000 n=12}
_Types	_4,065,846	_4,065,846	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{5,826,310k (± 0.02%)}	_{5,826,166k (± 0.02%)}	_~	_5,824,366k	_5,829,787k	_{p=0.887 n=12}
_{Memory Allocs}	_{59,303,049 (± 0.03%)}	_{59,299,628 (± 0.02%)}	_~	_59,284,854	_59,334,865	_{p=0.932 n=12}
_{Config Time}	_{0.076s (± 0.37%)}	_0.076s	_~	_~	_~	_{p=0.217 n=12}
_{Parse Time}	_{1.793s (± 1.53%)}	_{1.822s (± 3.07%)}	_~	_1.729s	_1.975s	_{p=0.965 n=12}
_{Bind Time}	_{0.772s (±11.01%)}	_{0.705s (±13.37%)}	_~	_0.511s	_0.914s	_{p=0.319 n=12}
_{Check Time}	_{15.030s (± 0.71%)}	_{15.112s (± 0.90%)}	_~	_14.872s	_15.377s	_{p=0.401 n=12}
_{Emit Time}	_{5.577s (± 5.92%)}	_{5.322s (± 5.19%)}	_~	_4.682s	_5.769s	_{p=0.235 n=12}
_{Total Time}	_{23.340s (± 1.18%)}	_{23.125s (± 0.79%)}	_~	_22.666s	_23.439s	_{p=0.124 n=12}
_{webpack - native}
_Errors	₅₉₈	₅₉₈	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_1,398,880	_1,398,880	_~	_~	_~	_{p=1.000 n=12}
_Types	_674,795	_674,795	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{887,239k (± 0.01%)}	_{887,473k (± 0.02%)}	_{+234k (+ 0.03%)}	_887,052k	_887,977k	_{p=0.017 n=12}
_{Memory Allocs}	_{6,938,712 (± 0.04%)}	_{6,938,072 (± 0.03%)}	_~	_6,935,913	_6,945,732	_{p=1.000 n=12}
_{Config Time}	_0.009s	_0.009s	_~	_~	_~	_{p=1.000 n=12}
_{Parse Time}	_{0.313s (± 3.59%)}	_{0.307s (± 3.15%)}	_~	_0.293s	_0.340s	_{p=0.385 n=12}
_{Bind Time}	_{0.081s (± 8.58%)}	_{0.081s (± 9.45%)}	_~	_0.070s	_0.113s	_{p=0.921 n=12}
_{Check Time}	_{2.682s (± 0.38%)}	_{2.676s (± 0.48%)}	_~	_2.653s	_2.714s	_{p=0.370 n=12}
_{Emit Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Total Time}	_{3.124s (± 0.31%)}	_{3.111s (± 0.52%)}	_~	_3.063s	_3.145s	_{p=0.417 n=12}
_{xstate-main - native}
_Errors	₀	₀	_~	_~	_~	_{p=1.000 n=12}
_Symbols	_1,060,810	_1,060,810	_~	_~	_~	_{p=1.000 n=12}
_Types	_389,671	_389,671	_~	_~	_~	_{p=1.000 n=12}
_{Memory Used}	_{471,807k (± 0.02%)}	_{471,858k (± 0.03%)}	_~	_471,609k	_472,265k	_{p=0.514 n=12}
_{Memory Allocs}	_{4,219,996 (± 0.07%)}	_{4,218,673 (± 0.06%)}	_~	_4,210,489	_4,223,674	_{p=0.443 n=12}
_{Config Time}	_{0.003s (±11.61%)}	_{0.003s (± 6.23%)}	_~	_0.002s	_0.003s	_{p=0.317 n=12}
_{Parse Time}	_{0.131s (± 2.52%)}	_{0.136s (± 3.35%)}	_~	_0.124s	_0.146s	_{p=0.091 n=12}
_{Bind Time}	_{0.054s (±12.43%)}	_{0.043s (±16.68%)}	_{🟩-0.010s (-19.31%)}	_0.034s	_0.065s	_{p=0.027 n=12}
_{Check Time}	_{1.086s (± 0.54%)}	_{1.085s (± 0.95%)}	_~	_1.068s	_1.113s	_{p=0.468 n=12}
_{Emit Time}	_0.000s	_0.000s	_~	_~	_~	_{p=1.000 n=12}
_{Total Time}	_{1.283s (± 0.67%)}	_{1.274s (± 0.88%)}	_~	_1.245s	_1.296s	_{p=0.385 n=12}

System info unknown

Hosts

native

Scenarios

Compiler-Unions - native
angular-1 - native
mui-docs - native
strada-build-src - native
strada-compiler - native
ts-pre-modules - native
vscode - native
webpack - native
xstate-main - native

_Benchmark	_Name	_Iterations
_Current	_pr	₁₂
_Baseline	_baseline	₁₂

Developer Information:

Download Benchmarks

typescript-automation · 2026-10-19T17:45:11Z

Wesley Wigham (@weswigham) Here are the results of running the user tests with tsc comparing baseline and pr:

Everything looks good!

typescript-automation · 2026-10-19T18:17:31Z

Wesley Wigham (@weswigham) Here are the results of running the top 400 repos with tsc comparing baseline and pr:

Everything looks good!

Jake Bailey (jakebailey) · 2026-10-19T19:30:20Z

+// A concurrency of 1 runs the functions on the goroutine that calls RunAndWait; 0 means no limit.
+func NewWorkGroup(concurrency int) WorkGroup {


Why is all of this change needed? Why can't we just do a parallel work group and then use a bounded semaphore where needed?

Because "where needed" depends on the resource you're trying to limit based on - when that resource is "system cores", "where needed" is everywhere the workgroup is used, so for a case like this one, which reuses the same workgroup at multiple task levels, requires threading a semaphore to a bunch of places, alongside the workgroup itself.

It's just nicer to build the concurrency limiter into the concurrency abstraction itself, imo, and the existing singleThreaded parameter was already a concurrency limit - just not as configurable as needed.

Copilot

🔵 Needs a closer look

Concurrent incremental invalidation warrants human review supported by race-enabled testing and rebuild-output comparisons.

No open issues 🎉

_{Review effort: Balanced}

Jake Bailey (jakebailey)

I guess it's fine, just feels at least a little inconsistent with other parts of the codebase that maybe could make use of this.

Copilot AI balanced review requested due to automatic review settings October 6, 2026 20:42

github-project-automation Bot added this to PR Backlog Oct 6, 2026

typescript-automation Bot added the For Uncommitted Bug PR for untriaged, rejected, closed or missing bug label Oct 6, 2026

github-project-automation Bot moved this to Not started in PR Backlog Oct 6, 2026

Gadzhi Gadzhiev (resure) mentioned this pull request Oct 6, 2026

Index re-exporting modules for declaration emit #64469

Merged

Copilot started reviewing on behalf of Gadzhi Gadzhiev (resure) October 6, 2026 20:43

View session

Copilot AI reviewed Oct 6, 2026

View reviewed changes

Comment thread tsc/internal/execute/incremental/affectedfileshandler.go

Bound signature computation for changed files too

a975ba5

The limit only covered files reached through references, so a rebuild with many directly changed files still started all of their declaration emits at once. Take the semaphore inside computeDtsSignature instead.

typescript-automation Bot assigned John Favret (johnfav03) Oct 6, 2026

Gadzhi Gadzhiev (resure) requested a balanced review from Copilot October 6, 2026 20:57

Copilot started reviewing on behalf of Gadzhi Gadzhiev (resure) October 6, 2026 20:58

View session

Copilot AI reviewed Oct 6, 2026

View reviewed changes

Wesley Wigham (weswigham) reviewed Oct 7, 2026

View reviewed changes

Gadzhi Gadzhiev (resure) added 4 commits October 8, 2026 19:46

Limit signature concurrency in the work group

7f0e5e1

Keep a changed default library file out of the affected set

8eb7a75

Merge remote-tracking branch 'origin/main' into fix/parallel-signatur…

4d50c86

…e-computation

Drop the scenario and benchmark that existing tests already cover

d0741eb

Gadzhi Gadzhiev (resure) requested a review from Wesley Wigham (weswigham) October 19, 2026 11:34

Wesley Wigham (weswigham) approved these changes Oct 19, 2026

View reviewed changes

github-project-automation Bot moved this from Not started to Needs merge in PR Backlog Oct 19, 2026

Wesley Wigham (weswigham) requested a review from Andrew Branch (andrewbranch) October 19, 2026 16:42

Jake Bailey (jakebailey) reviewed Oct 19, 2026

View reviewed changes

Jake Bailey (jakebailey) requested a balanced review from Copilot October 20, 2026 20:44

Copilot started reviewing on behalf of Jake Bailey (jakebailey) October 20, 2026 20:45

View session

Copilot AI reviewed Oct 20, 2026

View reviewed changes

Jake Bailey (jakebailey) approved these changes Oct 20, 2026

View reviewed changes

		// A concurrency of 1 runs the functions on the goroutine that calls RunAndWait; 0 means no limit.
		func NewWorkGroup(concurrency int) WorkGroup {

Conversation

Gadzhi Gadzhiev (resure) commented Oct 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

typescript-automation Bot commented Oct 6, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot review overview

🟡 Changes recommended

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Copilot review overview

🔵 Needs a closer look

Uh oh!

Wesley Wigham (weswigham) left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gadzhi Gadzhiev (resure) commented Oct 8, 2026

Uh oh!

Wesley Wigham (weswigham) left a comment

Choose a reason for hiding this comment

Uh oh!

typescript-automation Bot commented Oct 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

typescript-automation Bot commented Oct 19, 2026

Uh oh!

typescript-automation Bot commented Oct 19, 2026

tsc

Uh oh!

typescript-automation Bot commented Oct 19, 2026

Uh oh!

typescript-automation Bot commented Oct 19, 2026

Uh oh!

Jake Bailey (jakebailey) Oct 19, 2026

Choose a reason for hiding this comment

Uh oh!

Wesley Wigham (weswigham) Oct 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🔵 Needs a closer look

Uh oh!

Jake Bailey (jakebailey) left a comment

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Gadzhi Gadzhiev (resure) commented Oct 6, 2026 •

edited

Loading

Wesley Wigham (weswigham) left a comment •

edited

Loading

typescript-automation Bot commented Oct 19, 2026 •

edited

Loading

Wesley Wigham (weswigham) Oct 19, 2026 •

edited

Loading