feat: support virtual threads (#190, upstream #896) by devingryu · Pull Request #51 · astubbs/parallel-consumer

devingryu · 2026-06-04T00:36:51Z

Copy of confluentinc#908

Adds option to use Virtual Threads for worker pool. (See also: #896)

VT support: Added the useVirtualThreads option and execution logic to support Java 21+ Virtual Threads (Project Loom).
VT Pinning prevention: Replace synchronization method from synchronized blocks to ReentrantLock to prevent VT pinning.
ExecutorService Abstraction: Generalized the return type of setupWorkerPool to ExecutorService and improved queue management and backpressure logic accordingly.

Concerns

Test Environment Compatibility
The newly added VT-related tests require JDK 21+ and are configured to skip execution using Assumptions if the environment does not support it. It seems that current CI environment is based on JDK 17, if so the tests I added will be skipped in CI.
Concurrency in isPoolQueueLow
When VT mode is enabled, we cannot directly query the queue size, so WorkerManager.numberRecordsOutForProcessing is used to calculate the load. Please review if this approach creates any potential concurrency issues in a multi-threaded environment.
Defensive Logic
To ensure the stability of the existing logic, if VT is disabled (!useVirtualThreads), setupWorkerPool is enforced to return a ThreadPoolExecutor (throwing an exception otherwise), and type checks have been added. I am concerned this might introduce a breaking change (compatibility issue) for existing users who inherit AbstractParallelEoSStreamProcessor to use custom Executors.

Checklist

Documentation (if applicable)
Changelog

Copilot

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds optional Virtual Thread (JDK 21+) execution for the worker pool and refactors several synchronization points from synchronized to ReentrantLock, along with new tests and release notes updates.

Changes:

Introduces useVirtualThreads option with JVM capability validation.
Updates worker pool abstractions from ThreadPoolExecutor to ExecutorService and adds VT-specific behavior.
Replaces synchronized blocks/methods with ReentrantLock in metrics, producer transaction begin, load factor stepping, and supplier memoization.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
parallel-consumer-vertx/src/main/java/io/confluent/parallelconsumer/vertx/VertxParallelEoSStreamProcessor.java	Adapts override signature to `ExecutorService` to match new worker pool abstraction.
parallel-consumer-core/src/test/java/io/confluent/parallelconsumer/AbstractParallelEoSStreamProcessorConfigurationTest.java	Adds VT-focused tests and refactors module setup for tests.
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/metrics/PCMetrics.java	Switches close/remove locking from `synchronized` to `ReentrantLock`.
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/ProducerManager.java	Replaces synchronized transaction-begin guard with an explicit lock.
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/ExternalEngine.java	Adapts override signature to `ExecutorService`.
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/DynamicLoadFactor.java	Refactors stepping synchronization to `ReentrantLock`.
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/internal/AbstractParallelEoSStreamProcessor.java	Adds VT worker pool creation and generalizes worker pool type; introduces lock-based commit coordination and VT-safe pool stats/queue handling.
parallel-consumer-core/src/main/java/io/confluent/parallelconsumer/ParallelConsumerOptions.java	Adds `useVirtualThreads` flag + validation for VT support.
parallel-consumer-core/src/main/java/io/confluent/csid/utils/SupplierUtils.java	Refactors memoization locking from `synchronized` to `ReentrantLock`.
README.adoc	Notes the new VT feature and lock refactor in release notes.
CHANGELOG.adoc	Notes the new VT feature and lock refactor in changelog.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

+        workerThreadPool = SupplierUtils.memoize(() -> {
+            ExecutorService executor = setupWorkerPool(newOptions.getMaxConcurrency());
+
+            if (!options.isUseVirtualThreads() && !(executor instanceof ThreadPoolExecutor)) {
+                throw new IllegalStateException(
+                        "When Virtual Threads are disabled, the worker pool must be an instance of ThreadPoolExecutor. " +
+                                "If you are using a custom ExecutorService, make sure it extends ThreadPoolExecutor."
+                );
+            }
+            return executor;
+        });


+    protected ExecutorService setupWorkerPool(int poolSize) {
+        if (options.isUseVirtualThreads()) {
+            try {
+                // Thread.ofVirtual().name("pc-vt-").factory()
+                Object builder = Class.forName("java.lang.Thread").getMethod("ofVirtual").invoke(null);
+                Class<?> builderClass = Class.forName("java.lang.Thread$Builder");
+                builderClass.getMethod("name", String.class, long.class).invoke(builder, "pc-vt-", 0);
+                ThreadFactory factory = (ThreadFactory) builderClass.getMethod("factory").invoke(builder);
+
+                // Executors.newThreadPerTaskExecutor(factory)
+                return (ExecutorService) java.util.concurrent.Executors.class
+                        .getMethod("newThreadPerTaskExecutor", ThreadFactory.class)
+                        .invoke(null, factory);
+            } catch (Exception e) {
+                throw new IllegalStateException("Virtual threads not supported on this JVM", e);
+            }
+        }


+    private void validateVirtualThreadsSupport() {
+        if (useVirtualThreads) {
+            try {
+                // Thread.ofVirtual(), Executors.newThreadPerTaskExecutor(ThreadFactory)
+                Class.forName("java.lang.Thread").getMethod("ofVirtual");
+                java.util.concurrent.Executors.class.getMethod("newThreadPerTaskExecutor", java.util.concurrent.ThreadFactory.class);
+            } catch (NoSuchMethodException | ClassNotFoundException e) {
+                throw new UnsupportedOperationException(
+                        "useVirtualThreads is enabled, but the current JVM does not support Virtual Threads or the required ExecutorService."
+                );
+            }
+        }
    }


+    public void removeMeter(Meter meter) {
+        lock.lock();
+        try {
+            if (meter != null) {
+                removeMeter(meter.getId());
+            }
+        } finally {
+            lock.unlock();
        }
    }


+    @Test
+    void testVirtualThreadActivationAndConcurrencyLimit() throws Exception {
+        Assumptions.assumeTrue(isVirtualThreadsSupported(), "JDK 21+ required for Virtual Threads");
+
+        int maxConcurrency = 10;
+        var vtOptions = ParallelConsumerOptions.<String, String>builder()
+                .consumer(consumer)
+                .useVirtualThreads(true)
+                .maxConcurrency(maxConcurrency)
+                .build();


+    private boolean isVirtualThreadsSupported() {
+        try {
+            Class.forName("java.lang.Thread").getMethod("ofVirtual");
+            return true;
+        } catch (Exception e) {
+            return false;
+        }
+    }


arishwin · 2026-06-08T10:17:54Z

Hi @astubbs , is there any plans to get this PR reviewed?

astubbs · 2026-07-27T23:22:53Z

@claude take a look at the review so far

claude · 2026-07-27T23:23:14Z

Claude finished @astubbs's task in 2m 26s —— View job

Claude's review of the VT support PR

Tasks

Gather context (PR body, diff, existing review comments)
Read changed files in detail
Cross-check the Copilot review comments for validity
Look for additional issues (bugs, concurrency, compatibility)
Post final review summary

I read through the diff (f54e0d5..HEAD, the 4 commits on this branch) and checked each of Copilot's inline comments against the actual code.

On the existing Copilot comments

Comment	Verdict
Non-VT path now requires `ThreadPoolExecutor` (`AbstractParallelEoSStreamProcessor.java:307`)	Valid. This is a real behavioral break for anyone who overrode `setupWorkerPool()` to supply a custom `ExecutorService` (e.g. a `ForkJoinPool`-backed one). Given the code already does `instanceof ThreadPoolExecutor` checks everywhere metrics are read (`getQueueTargetLoaded`, `isPoolQueueLow`, `getNumberOfUserFunctionsQueued`, `getPoolActiveCount`, `clearWorkerQueue`), it would degrade gracefully without the hard `IllegalStateException` at all. I'd drop the enforced-type check, or at minimum validate it in `ParallelConsumerOptions.validate()` with a clearer message tied to the specific option.
`poolSize` ignored for VT, unbounded submission (`AbstractParallelEoSStreamProcessor.java:361`)	Valid, and worth taking seriously — `maxConcurrency` is documented/relied on elsewhere as a hard cap. `isPoolQueueLow()` in VT mode gates on `wm.getNumberRecordsOutForProcessing() <= options.getTargetAmountOfRecordsInFlight()`, so in practice the control loop should stop feeding new work once the target is hit, but nothing stops a burst of concurrently-submitted tasks from briefly exceeding it since there's no semaphore/gate at submission time. Worth at least documenting that concurrency limiting is soft/best-effort under VT, if not adding a bound.
`UnsupportedOperationException` drops the cause (`ParallelConsumerOptions.java:478`)	Valid, and a quick fix: `throw new UnsupportedOperationException("...", e)`. Note the analogous failure path in `setupWorkerPool()` (line 375) already does this correctly (`new IllegalStateException("...", e)`) — just needs to match here too.
`PCMetrics.removeMeter(Id)` not on the same lock as `removeMeter(Meter)`	Checked — not an actual bug. The private `removeMeter(Meter.Id)` overload is only ever invoked from the public `removeMeter(Meter)` (all external callers in `PartitionState`, `PartitionStateManager`, `WorkManager` use the `Meter` overload), and that call happens while the caller already holds `lock` — since `ReentrantLock` is reentrant this is safe. No other caller reaches the `Id` overload directly, so mutual exclusion is preserved.
Test name `testVirtualThreadActivationAndConcurrencyLimit` doesn't test the concurrency cap	Valid — the test only asserts a submitted task runs on a virtual thread; it never submits > `maxConcurrency` tasks or observes an in-flight cap. Either rename it or add the missing assertion (ties into the `poolSize` concern above).
Test's `isVirtualThreadsSupported()` only checks `Thread.ofVirtual`, not `Executors.newThreadPerTaskExecutor`	Valid — production's `validateVirtualThreadsSupport()` in `ParallelConsumerOptions.java:471-482` checks both reflectively; the test assumption should mirror that so a JDK with one-but-not-the-other doesn't skip inconsistently between test and prod paths.

Additional observations

The reflection-based use of Thread.ofVirtual()/Executors.newThreadPerTaskExecutor(...) (AbstractParallelEoSStreamProcessor.java:362-377) is necessary rather than gratuitous — pom.xml targets release.target=8 for the core module, so the JDK 21 API can't be referenced directly. Worth a short comment at the top of setupWorkerPool() explaining why reflection is used here, since it's non-obvious from the code alone and the next person touching this may be tempted to "simplify" it into a direct call that breaks the JDK 8 build.
The commitCommand/ReentrantLock and other synchronized→ReentrantLock refactors (DynamicLoadFactor, ProducerManager.syncBeginTransaction, SupplierUtils.memoize) all look correct — same critical sections, proper try/finally unlocking, and since none of these locks were ever waited-on across blocking I/O, the original synchronized blocks weren't actually pinning-prone in a way that changes behavior; the refactor is a reasonable defensive move for VT-safety regardless.
isPoolQueueLow()'s VT branch reuses WorkManager.numberRecordsOutForProcessing (a plain, non-atomic int field), matching the PR author's own concern Java 17 #2. This field is already read/written this way in several other places in WorkManager for the same control-loop-thread-only access pattern, so it's not a new risk introduced by this PR — just worth confirming (as the author already flagged) that all the call sites of getNumberRecordsOutForProcessing()/its mutators stay confined to the single control thread.
The useVirtualThreads javadoc on ParallelConsumerOptions (~line 590-597) correctly warns that VT overrides managedExecutorService/managedThreadFactory, which is good — but that override happens silently at runtime rather than being validated in .validate() (e.g. rejecting the combination outright, or logging a warning), so a user who sets both could be surprised.

Summary

The two most actionable items from the existing review are the forced ThreadPoolExecutor type check (real compatibility break for custom-executor users, flagged by the PR author too) and the missing exception cause in ParallelConsumerOptions — both small, well-scoped fixes. The poolSize-as-a-cap-under-VT question is the one with the most design weight and worth explicit maintainer input before merge, since it affects the meaning of maxConcurrency for VT users. The PCMetrics locking comment from Copilot does not hold up under inspection. I have not implemented any changes, per the request to just look at the review so far — happy to pick up specific fixes if asked.

The rebuilt ledger opened with a table of every open PR, its branch, its worktree and its ahead/behind counts. That is a second PR tracker: `gh pr list` is always right, this table is wrong within a day, and a reader cannot tell which one they are looking at. Same for branch divergence and worktree paths, which `git` and bin/worktree-status.sh already report. Replaced with the part no command can answer - #29/#31 pointing at the pinned mirror and why the retarget is not mechanical, #38 blocked on a missing ArchUnit engine rather than the version bump, #51 colliding with #57 over PCMetrics, and which PR owns which files. Divergence counts are dropped throughout; what stays is the consequence ("rebase before review"), not the number behind it. Measured flake rates stay - an experiment's results are not re-derivable from a command. The rule is in the header, where the file's other writing rules live. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

A bare #NN means THIS fork. A bare number above the fork's own highest issue is therefore almost always an upstream reference pointing at the wrong repo - harmless-looking today, and wrong for real once the fork's numbering reaches it. Now that every upstream issue is mirrored, there is nearly always a fork number to use instead. The gate runs in the existing PR Checklist job, on ADDED lines only, and adapts as the repo grows: it reads the fork's current highest issue number from the API rather than hard-coding a threshold that rots. Three files are exempt because a bare number legitimately means upstream in them - CHANGELOG.adoc (its own header says entries below 0.6.0.0 predate the fork), upstream-map.yaml (every number is upstream by construction), and upstream-pr-analysis.adoc. Those are named in the module rather than left to judgement because a naive sweep on 2026-08-05 rewrote exactly those three wrongly. Same reason the rule skips javadoc member links, code spans and URLs. Escape hatch mirrors the changelog gate: "issue-refs: N/A - <reason>". Logic is a testable module with 11 assertions running before the gate, following changelog-ref-gate.js - that gate has shipped two real misjudgements, so this one proves its own rules first. PHASE 5 finished. Five single-mirror PRs carry both numbers in the title (#29, #31, #51, #57, #116). #53 and #106 span or only partly address several mirrors, so they get a Related issues section listing them WITHOUT a Fixes keyword - verified 0 closing references on each. A title listing three mirror numbers helps nobody, and Fixes on partial work is the error the #233 / #326 / confluentinc#857 mirrors already document. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QqHpNSXC39ANv9kG1ZvUzn

astubbs · 2026-08-06T00:37:25Z

Review note: the changelog hunk needs removing

CHANGELOG.adoc is no longer a per-PR chore. PR #113 (commit e3b1601e, on master) moved release notes to generation from the commit log at release time, and AGENTS.md -> Changelog now says: "Nothing about it is a per-PR chore. Do not add entries in a feature PR." This PR predates that, so its entries are not a mistake by anyone - they just need dropping when you next update from master.

Why removing them loses nothing: the section for the release being cut is generated from git log <last-tag>..HEAD, so this work still gets described - assembled as a set, with related commits merged and the wording rewritten for a reader who was not here. That is the part a per-PR entry could never do.

What it asks of you instead: the commit message is now the raw material. A subject that says what changed and, where it matters, what it changed for a user - with the diagnosis and rejected alternatives in the body.

Specific to this PR

Two hunks: === Features / * feature: add options to enable virtual threads, and === Improvements / * refactor: migrate synchronized into ReentrantLock.

Worth noting the second would not earn an entry under the new rules even at release time. The entry test is "can a user or operator observe this without reading our repo - API, behaviour, performance, logs and metrics, or the published artifact?" A synchronized -> ReentrantLock migration is invisible unless it changed behaviour or contention characteristics. The virtual-threads option is clearly user-visible and will survive generation.

* Added boolean useVirtualThreads in ParallelConsumerOptions * Generalize workerThreadPool logics to handle Virtual Threads * Added tests refactor: migrate synchronized into ReentrantLock * prevents virtual threads pinning fix: disable load factor in queue target for vt * Bypasses `DynamicLoadFactor` in `getQueueTargetLoaded()` when using VT.

devingryu · 2026-08-07T03:17:52Z

Cleaned CHANGELOG.adoc changes, squashed into single commit feature: add options to enable virtual threads since other comments are not necessary for end users to know.

…nish The sweep brings 37 of the 38 open PRs across mechanically. #51 is the exception and it is not a mechanical problem: its head lives on a contributor's fork, so there is no origin ref to work from and, more to the point, nowhere to put the result. A renamed local branch with no push destination is not a delivered result. Recorded rather than solved because every option is somebody's call - push to their fork if maintainer edits are on, ask the contributor to run the procedure, or close it - and because doing nothing has a deadline: once the rename lands, that PR's diff is against paths that no longer exist. The two lower-priority items are recorded with it: the required `dups: similarity` check false-positives on any renamed branch, because its base comparison is keyed by file path; and the accelerators URL that the path-form scan reads as a package, which is 2 branches and does not inherit the #289 conflict-free argument. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…shape most of it shared Written after the sweep rather than before it, so it records measurements instead of expectations. The plan predicted one blocker per branch. There were six classes, and five of them had nothing to do with renaming: they were master cleanups that older branches did not have. B, D, E and the license plugin are all the same shape - a change that landed "ahead of the rename so it stays mechanical", which made it mechanical only for branches containing it. That is the lesson worth carrying out of this, and it is why a future sweep screens for its prerequisites up front instead of meeting them one refusal at a time. C is the one that generalises past this project: `git checkout <ref> -- <file>` is a whole-file overwrite, so a branch's own contribution to that file goes with it, and the failure surfaces four steps downstream looking like rename damage. Also here: the real merge cost, measured rather than rehearsed (3 conflicts on a small branch, 22 on the largest, all mechanical); the mis-pairing fear retired with evidence, since branches carry seven, eight and ten of the near-identical arch tests and every one paired inside its own module at R100; and #51, the one branch this procedure cannot finish, recorded as needing a human because its head lives on a fork and there is nowhere to put the result. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

…ttering drafts The first cut of the ladder let three kinds of overstatement through, all named in review: - 'implemented' now means the implementation intended to ship. A draft that will be replaced is at most a poc, and a draft that is not even the surviving direction does not advance the stage at all - so virtual-threads (#51 carries the upstream draft, not the fork's) drops to idea, and the health-check surface (#226, a working draft not yet accepted as the shipping surface) is a poc. - 'limited-poc' joins the ladder below poc: a slice runs but the central claim is not proven end-to-end. The Streams and Connect previews move there - 'poc' alone read as 'we proved we can do it', which neither spike claims. Java-and-Kafka drops to idea: compiling at 17 is exploration; the Java 11 + Kafka 4 work has not started. - 'planned' now means an implementation plan - the how. The self-tuning plan from #308 decides the what, so it is requirements-drafted. One promotion the review surfaced: the docs site has a drafted design on #316 (explicitly design only - no site is built there), so it moves from idea to planned. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…per test, qualified refs, retired links Three corpus repairs behind red gate lanes on this branch: - docs/quarantined-tests.md carried two live entries for PCMetricsTest.metricsRegisterBinding - the original mechanism diagnosis and the #265 re-quarantine - which the registry check rightly reads as drift. The re-quarantine entry is the current one; it now carries a pointer to the first diagnosis (which still stands, in bug-pcmetrics-committed-offset-vs-completion-count.md) and the superseded block is gone. History keeps the original. - docs/data/landing-page.yaml still linked docs/inflight/next-landing-page.md, retired by b0a5da3 when the owner dropped the workstream; both mentions are reworded inline, the same repair that commit applied to the six notes it caught. - Six inflight notes carried bare #NN refs on lines this stack adds vs master: each now names its repo (confluentinc#346/#390/#315/confluentinc#606, #51 - each resolved in both repos first), a quoted upstream issue body takes the line-scoped exempt marker, and two ordinals that were never issue refs at all ("problem 1", "hypothesis 6") are written as ordinals. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019HwDcZdfv1Ne4u3g6ThrG9

astubbs · 2026-08-27T00:22:00Z

Hi @devingryu , thanks for the contribution and the ideas! =D I've followed up since with a full virtual threads implementation that is also inline with all the other work going on: #360, so I'll close this PR.

… with its premise corrected Owner ruling, 2026-09-08, on the sweep's proposal 19. The note goes to `deferred - after v6` and keeps the audit as the record. Its central premise was corrected on the way rather than left for the next reader to trip on: `state` is volatile on master today, so the visibility half of the rows that named it is closed; the check-then-set race in pauseIfRunning/resumeIfPaused and the absent per-method contract are what the blocker rests on. #226 no longer carries the volatility change (it is the health-check surface PR) and #51 is closed, so the two bullets that described them as live work are rewritten. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W511R2TZFAqEiqgS5yogTv

Copilot AI review requested due to automatic review settings June 4, 2026 00:36

Copilot AI reviewed Jun 4, 2026

View reviewed changes

astubbs added the feature New capability or improvement to an existing one label Jul 28, 2026

claude Bot mentioned this pull request Aug 4, 2026

docs: audit the in-flight ledger against reality, then split it so PRs stop colliding #112

Merged

5 tasks done

astubbs changed the title ~~feat: support virtual threads~~ feat: support virtual threads (#190, upstream #896) Aug 5, 2026

claude Bot mentioned this pull request Aug 5, 2026

docs+ci: mirror upstream tracker, make issue references unambiguous, and clean up CI #114

Merged

4 tasks done

astubbs mentioned this pull request Aug 5, 2026

fix(logging) astubbs#169 astubbs#170: bound the dropped-batch and user-function-failure log lines #203

Merged

4 tasks done

This was referenced Aug 6, 2026

fix(core) astubbs#120: unbounded PCMetrics heap growth, with the confluentinc#905 hot-shard metric #57

Merged

docs(changelog): generation covers 0.6.0.0 now, not "from the next release on" #210

Merged

devingryu force-pushed the features/enable-virtual-threads branch from fca394a to b4d5c2d Compare August 7, 2026 03:14

astubbs mentioned this pull request Aug 12, 2026

refactor: move the packages to bz.stub.parallelconsumer (DO NOT SQUASH) #294

Merged

4 tasks done

astubbs self-requested a review as a code owner August 14, 2026 02:31

astubbs marked this pull request as draft August 19, 2026 03:06

astubbs closed this Aug 27, 2026

Navigation Menu

Repository navigation

feat: support virtual threads (#190, upstream #896) - #51

feat: support virtual threads (#190, upstream #896)#51
devingryu wants to merge 1 commit into
astubbs:masterfrom
devingryu:features/enable-virtual-threads

devingryu commented Jun 4, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

arishwin commented Jun 8, 2026

Uh oh!

astubbs commented Jul 27, 2026

Uh oh!

claude Bot commented Jul 27, 2026 •

edited

Loading

Uh oh!

astubbs commented Aug 6, 2026

Uh oh!

devingryu commented Aug 7, 2026

Uh oh!

astubbs commented Aug 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

devingryu commented Jun 4, 2026

Concerns

Checklist

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

arishwin commented Jun 8, 2026

Uh oh!

astubbs commented Jul 27, 2026

Uh oh!

claude Bot commented Jul 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Claude's review of the VT support PR

On the existing Copilot comments

Additional observations

Summary

Uh oh!

astubbs commented Aug 6, 2026

Review note: the changelog hunk needs removing

Specific to this PR

Uh oh!

devingryu commented Aug 7, 2026

Uh oh!

astubbs commented Aug 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

claude Bot commented Jul 27, 2026 •

edited

Loading