ci: Run RuboCop serially to avoid JRuby thread-parallel failures by kinyoklion · Pull Request #34 · launchdarkly/openfeature-ruby-server

kinyoklion · 2026-08-25T21:24:50Z

Run RuboCop serially, because --parallel is broken under JRuby as of RuboCop 1.90.0.

CI's build-linux (jruby-10.0) job started failing on main with no code change, purely from RuboCop floating from 1.89.0 to 1.90.0 (released 2026-08-24)
Parallelism buys nothing here: the repo has 15 files to inspect
No behavior change for the CRuby/Windows jobs beyond losing the (negligible) parallel speedup

Requirements

I have added test coverage for new or changed functionality
I have followed the repository's pull request submission guidelines
I have validated my changes against all supported platform versions

Related issues

Failing run: https://github.com/launchdarkly/openfeature-ruby-server/actions/runs/32897505749/job/97963432418

Implementation details

Root cause

The failing step emitted 1315 internal cop errors ("An error occurred while Layout/SpaceBeforeFirstArg cop was inspecting ...") plus 12 phantom offenses whose reported line/column did not match the source line printed alongside them (e.g. Layout/DefEndAlignment pointing at a comment). The offenses are not real; the AST node locations are wrong.

On JRuby, the parallel gem cannot fork, so Parallel.each takes its RUBY_PLATFORM.include?('java') branch and runs work in threads rather than worker processes. RuboCop 1.90 began preserving cop instances across files (rubocop/rubocop#11119), and RuboCop::Cop::Base documents the assumption that "under --parallel each worker process has its own cop instances, so state persists only within a worker's share of the files". Under threads that assumption does not hold: the reused cop instances see concurrent processed_source values, which is consistent with the mismatched locations. The thread/instance-sharing mechanism is a reading of the RuboCop source, not an upstream-confirmed diagnosis.

Verification (local, Java 21)

JRuby	RuboCop	`--parallel`	serial
10.0.4.0	1.90.0	fails	clean
10.0.6.0	1.90.0	fails	clean
10.1.1.0	1.90.0	fails	clean
10.0.4.0	1.89.0	clean	clean

So no JRuby upgrade avoids this, and pinning RuboCop would only defer it.

Alternatives considered

Pin rubocop to ~> 1.89.0 in the Gemfile: hides the problem and freezes lint at an old version.
Skip the RuboCop step entirely on JRuby: also works (the CRuby job covers lint), but drops JRuby-specific coverage for no benefit over running serially.
Set AllCops: ParserEngine: parser_whitequark: not validated, and does not address the thread-safety issue.

Link to Devin session: https://app.devin.ai/sessions/47847578334a4bd497c24e3859630cd2
Requested by: @kinyoklion

Note

Overview
CI’s shared RuboCop step no longer passes --parallel, so lint runs serially on every Ruby platform.

That sidesteps RuboCop 1.90’s broken parallel path on JRuby (threads reuse cop instances and produce bogus offenses). With only ~15 files, the parallel speedup was negligible anyway.

^{Reviewed by Cursor Bugbot for commit ae9f49b. Bugbot is set up for automated code reviews on this repo. Configure here.}

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

devin-ai-integration · 2026-08-25T21:24:53Z

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

Disable automatic comment, CI, and merge conflict monitoring

devin-ai-integration · 2026-08-25T21:24:56Z

@cursor review

@kinyoklion

Run RuboCop serially, mirroring launchdarkly/openfeature-ruby-server#34, because `--parallel` is broken under JRuby as of RuboCop 1.90.0. - The shared `check` composite action runs on `jruby-9.4`, and the gemspec's `rubocop "~> 1.76"` floats to 1.90.0 (released 2026-08-24), so this repo is exposed to the same failure - Parallelism buys little here, and the CRuby jobs only lose a negligible speedup **Requirements** - [ ] I have added test coverage for new or changed functionality - [x] I have followed the repository's [pull request submission guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests) - [x] I have validated my changes against all supported platform versions **Related issues** launchdarkly/openfeature-ruby-server#34 <details> <summary>Implementation details</summary> **Root cause** (from the investigation in openfeature-ruby-server#34) Under JRuby the `parallel` gem cannot fork, so it runs work in threads instead of worker processes. RuboCop 1.90 began preserving cop instances across files, and `RuboCop::Cop::Base` documents the assumption that each `--parallel` worker is its own process with its own cop instances. With threads that assumption breaks: reused cop instances see concurrent `processed_source` values, producing internal cop errors and phantom offenses with mismatched locations. The mechanism is a reading of the RuboCop source, not an upstream-confirmed diagnosis. Verified there (JRuby 10.0.4/10.0.6/10.1.1 with RuboCop 1.90.0: `--parallel` fails, serial clean; RuboCop 1.89.0: both clean), so no JRuby upgrade avoids it and pinning RuboCop only defers it. **Scope** Only `.github/actions/check/action.yml` changes; that action is used by `ci.yml`, `build-gem.yml`, `release-please.yml`, and the manual publish workflows, so all of them pick up the serial run. **Alternatives considered** - Pin `rubocop` to `~> 1.89.0`: hides the problem and freezes lint at an old version. - Skip RuboCop on JRuby: works, but drops JRuby-specific lint coverage for no benefit over running serially. </details> Link to Devin session: https://app.devin.ai/sessions/feaff386987f4b3db39becb95bce9fa4 Open in Devin Desktop: https://app.devin.ai/desktop/session/feaff386987f4b3db39becb95bce9fa4?variant=devin Requested by: @kinyoklion  --- > [!NOTE] > **Overview** > The shared **Quality control checks** composite action (`.github/actions/check/action.yml`) now runs `bundle exec rubocop` without `--parallel`, so RuboCop executes serially on every workflow that uses this action (CI, gem build, release, etc.). > > This avoids JRuby CI failures introduced with RuboCop 1.90, where thread-based “parallel” workers reuse cop instances and trigger internal errors and bogus offenses; serial execution matches the fix used in launchdarkly/openfeature-ruby-server#34. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 8b0080f. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

@kinyoklion

Resolve dependencies only to gem versions that have been public for at least seven days, using Bundler's [cooldown](https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html). - No pinning and no lockfile: we still get the newest version matching each constraint, just not one published in the last week - `launchdarkly-server-sdk` is exempt, so a constraint bump right after our own release still resolves - Requires Bundler >= 4.0.13, so CI pins Bundler to 4.0.19 on the `setup-ruby` step - Contributors on Bundler 2.x are unaffected — the setting is silently ignored, so they simply resolve to the newest versions **Requirements** - [ ] I have added test coverage for new or changed functionality - [x] I have followed the repository's [pull request submission guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests) - [x] I have validated my changes against all supported platform versions **Related issues** Follow-up to #34: the RuboCop 1.90.0 breakage that PR works around would have been held out of CI by this cooldown. <details> <summary>Implementation details</summary> **How it works** `source "https://rubygems.org", cooldown: 7` makes Bundler consult the per-version `created_at` timestamp in rubygems.org's v2 compact index during resolution and pass over any version younger than the window. Versions whose source does not expose `created_at` (private registries, pre-v2 entries) stay resolvable, so this never silently blocks a resolution. `--cooldown 0` / `BUNDLE_COOLDOWN=0` is the escape hatch when the newest release is exactly the one you want, e.g. a security fix. **Why the second source block** Cooldown is stored per remote URI (`Bundler::Source::Rubygems#remote_cooldowns`), with no per-gem option, and a second `source` block for the *same* URI does not get its own value. Naming the registry's index host gives a distinct remote that can carry `cooldown: 0`: ```ruby source "https://index.rubygems.org", cooldown: 0 do gem "launchdarkly-server-sdk" end ``` Without this, `cooldown: 7` fails resolution outright today: our gemspec requires `launchdarkly-server-sdk ~> 8.15`, 8.15.0 was published 2026-08-20, and no older version satisfies the constraint, so every candidate is inside the window. ``` The source contains the following gems matching 'launchdarkly-server-sdk (~> 8.15)': * launchdarkly-server-sdk-8.15.0-java * launchdarkly-server-sdk-8.15.0 ... version solving has failed. ``` Exempting it is also the right policy: we publish that gem, so it is not the untrusted-third-party case cooldown defends against. **Verification** Ran locally in containers against this branch (no lockfile, Bundler 4.0.19): | Runtime | Result | | --- | --- | | CRuby 3.4.10 | `rubocop 1.90.0 (available in 6 days), resolved 1.89.0 instead`; `launchdarkly-server-sdk 8.15.0` resolved; 73 examples 0 failures; 15 files inspected, no offenses | | JRuby 10.0.6.0 | same, including the `-java` platform gem through the exempt remote | Also confirmed Bundler 2.6.9 (Ruby 3.4's default) resolves the same Gemfile without error, ignoring the `cooldown:` option. **Alternatives considered** - `cooldown: 3` with no exemption: shorter window, and still breaks for three days after each of our own SDK releases. - Commit a `Gemfile.lock` and let Dependabot bump it with a cooldown: gives an auditable dependency history, but pins a library to specific versions and stops testing against the newest supported ones. - `bundle config set cooldown` / `BUNDLE_COOLDOWN` in the CI workflow only: leaves local `bundle install` unprotected, and cannot express a per-source exemption. - The `bundle-safe-update` gem (pre-dates Bundler's feature): a low-adoption single-maintainer dependency, which is itself supply-chain risk. </details> Link to Devin session: https://app.devin.ai/sessions/47847578334a4bd497c24e3859630cd2 Requested by: @kinyoklion  --- > [!NOTE] > **Overview** > CI and local installs now resolve gems from rubygems.org only if the version has been published for **at least seven days**, using Bundler’s `cooldown` on the main `Gemfile` source—without adding a lockfile or pinning versions beyond existing constraints. > > **`launchdarkly-server-sdk`** is pulled through a second source (`index.rubygems.org` with `cooldown: 0`) so first-party releases still resolve immediately; the PR description notes this is required because the current `~> 8.15` constraint would otherwise fail resolution. > > **GitHub Actions** pins **Bundler 4.0.19** on `ruby/setup-ruby` in the shared CI composite action and the Windows workflow so cooldown is honored in CI. **CONTRIBUTING.md** documents the behavior, the Bundler 4.0.13+ requirement, and `--cooldown 0` for urgent updates. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit a2cca54. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

@kinyoklion

Resolve dependencies only to gem versions that have been public for at least seven days, using Bundler's [cooldown](https://blog.rubygems.org/2026/06/03/cooldown-let-new-gems-be-vetted.html). Equivalent of launchdarkly/openfeature-ruby-server#35. - No pinning and no lockfile: we still get the newest version matching each constraint, just not one published in the last week - `ld-eventsource` is exempt, so the exact-version bump right after one of its releases still resolves - Requires Bundler >= 4.0.13, so CI pins Bundler to 4.0.19 — except on `jruby-9.4`, which is Ruby 3.1 and cannot install Bundler 4 at all, so it stays on Bundler 2 and resolves without a cooldown - Because that job has no cooldown, this PR also runs RuboCop serially (openfeature-ruby-server#34): `--parallel` is broken under JRuby as of RuboCop 1.90.0, which the `jruby-9.4` job picks up regardless - Contributors on Bundler 2.x are unaffected — the setting is silently ignored, so they simply resolve to the newest versions **Requirements** - [ ] I have added test coverage for new or changed functionality - [x] I have followed the repository's [pull request submission guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests) - [x] I have validated my changes against all supported platform versions **Related issues** Port of launchdarkly/openfeature-ruby-server#35 and, for the RuboCop step, launchdarkly/openfeature-ruby-server#34. <details> <summary>Implementation details</summary> **How cooldown works** `source "https://rubygems.org", cooldown: 7` makes Bundler consult the per-version `created_at` timestamp in rubygems.org's v2 compact index during resolution and pass over any version younger than the window. Versions whose source does not expose `created_at` (private registries, pre-v2 entries) stay resolvable, so this never silently blocks a resolution. `--cooldown 0` / `BUNDLE_COOLDOWN=0` is the escape hatch when the newest release is exactly the one you want, e.g. a security fix. **Why the second source block** Cooldown is stored per remote URI (`Bundler::Source::Rubygems#remote_cooldowns`), with no per-gem option, and a second `source` block for the *same* URI does not get its own value. Naming the registry's index host gives a distinct remote that can carry `cooldown: 0`: ```ruby source "https://index.rubygems.org", cooldown: 0 do gem "ld-eventsource" end ``` The gemspec requires `ld-eventsource` at an exact version, deliberately, so that bugfixes there are always tied to a new SDK version. Without the exemption, the first seven days after each `ld-eventsource` release would be un-resolvable: every candidate satisfying the new exact constraint is inside the cooldown window. Exempting it is also the right policy — we publish that gem, so it is not the untrusted-third-party case cooldown defends against. **The `jruby-9.4` exception, and the RuboCop step** Bundler 4.0.19 requires Ruby >= 3.2, and JRuby 9.4 reports `RUBY_VERSION` 3.1.7: ``` ERROR: Error installing bundler: bundler-4.0.19 requires Ruby version >= 3.2.0. The current ruby version is 3.1.7. ``` So the shared setup action selects the Bundler version per runtime rather than pinning one for all of them, and the `jruby-9.4` job resolves with Bundler 2, which ignores `cooldown:`. That job therefore keeps installing brand-new gem versions — including RuboCop 1.90.0, whose `--parallel` mode is broken under JRuby, which failed the first CI run on this branch: ``` 1.90.0 (using Parser 3.3.12.0, rubocop-ast 1.50.0, analyzing as Ruby 3.1, running on jruby 3.1.7) [java] ``` On JRuby the `parallel` gem cannot fork, so it runs work in threads; RuboCop 1.90 began preserving cop instances across files, and shared cop instances seeing concurrent `processed_source` values produce thousands of internal cop errors and phantom offenses. Dropping `--parallel` fixes it, and parallelism is a negligible speedup on 185 files. openfeature-ruby-server does not have the Bundler gap because its matrix is on `jruby-10.0` (Ruby 3.4); moving this repo's matrix to `jruby-10` would let cooldown apply everywhere, but that is a supported-platform change and out of scope here. **Verification** Ran locally in containers against this branch (no lockfile): | Runtime | Bundler | Result | | --- | --- | --- | | CRuby 3.4.10 | 4.0.19 | `rubocop 1.90.0 (available in 4 days), resolved 1.89.0 instead`, same for `aws-partitions`; 1046 examples 0 failures; RuboCop clean | | CRuby 3.2 | 4.0.19 | same cooldown skips, resolution succeeds | | CRuby 3.4.10 | 2.6.9 | resolves the same Gemfile without error, ignoring `cooldown:` | | JRuby 9.4.15 | 2.6.9 | resolves without error (no cooldown), RuboCop 1.90.0: `--parallel` → 37497 internal cop errors and 965 phantom offenses; serial → 185 files inspected, no offenses | **Alternatives considered** - Pin Bundler 4.0.19 for every job: breaks the `jruby-9.4` job outright. - `cooldown: 3` with no exemption: shorter window, and still breaks for three days after each `ld-eventsource` release. - Commit a `Gemfile.lock` and let Dependabot bump it with a cooldown: gives an auditable dependency history, but pins a library to specific versions and stops testing against the newest supported ones. - `bundle config set cooldown` / `BUNDLE_COOLDOWN` in CI only: leaves local `bundle install` unprotected, and cannot express a per-source exemption. </details> Link to Devin session: https://app.devin.ai/sessions/9e2aad687cd743149ff71c0a1fcfd936 Open in Devin Desktop: https://app.devin.ai/desktop/session/9e2aad687cd743149ff71c0a1fcfd936?variant=devin Requested by: @kinyoklion  --- > [!NOTE] > **Overview** > Adds a **seven-day cooldown** on the primary RubyGems source so `bundle install` prefers gem versions that have been public for at least a week, without pinning or committing a lockfile. > > **`ld-eventsource`** is pulled through a second source (`index.rubygems.org`) with **`cooldown: 0`**, so first-party releases can still resolve immediately when the gemspec bumps an exact version. > > CI’s shared Ruby setup now installs **Bundler 4.0.19** on CRuby (needed for cooldown) and keeps **Bundler 2** on **`jruby-9`** matrix jobs, where Ruby 3.1 cannot run Bundler 4 and the cooldown setting is ignored anyway. > > **CONTRIBUTING.md** documents the cooldown, the `ld-eventsource` exemption, the Bundler 4 requirement, and **`--cooldown 0`** for emergency resolution. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit e9313b8. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

ci: Run RuboCop serially to avoid JRuby thread-parallel failures

ae9f49b

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

devin-ai-integration Bot assigned kinyoklion Aug 25, 2026

kinyoklion mentioned this pull request Aug 25, 2026

ci: Apply a Bundler cooldown to dependency resolution #35

Merged

2 of 3 tasks

kinyoklion marked this pull request as ready for review August 25, 2026 21:37

kinyoklion requested a review from a team as a code owner August 25, 2026 21:37

keelerm84 approved these changes Aug 26, 2026

View reviewed changes

kinyoklion merged commit ecb71d5 into main Aug 27, 2026
10 checks passed

kinyoklion deleted the devin/1787693052-drop-rubocop-parallel branch August 27, 2026 16:16

kinyoklion mentioned this pull request Aug 27, 2026

ci: Run RuboCop serially to avoid JRuby thread-parallel failures launchdarkly/ruby-server-sdk#424

Merged

2 of 3 tasks

devin-ai-integration Bot mentioned this pull request Aug 27, 2026

ci: Apply a Bundler cooldown to dependency resolution launchdarkly/ruby-server-sdk#425

Merged

2 of 3 tasks

Navigation Menu

Repository navigation

ci: Run RuboCop serially to avoid JRuby thread-parallel failures - #34

ci: Run RuboCop serially to avoid JRuby thread-parallel failures#34
kinyoklion merged 1 commit into
mainfrom
devin/1787693052-drop-rubocop-parallel

kinyoklion commented Aug 25, 2026 •

edited by cursor Bot

Loading

Uh oh!

devin-ai-integration Bot commented Aug 25, 2026

Uh oh!

devin-ai-integration Bot commented Aug 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

kinyoklion commented Aug 25, 2026 • edited by cursor Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

devin-ai-integration Bot commented Aug 25, 2026

🤖 Devin AI Engineer

Uh oh!

devin-ai-integration Bot commented Aug 25, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

kinyoklion commented Aug 25, 2026 •

edited by cursor Bot

Loading