"Superseded by" comments are being propagated to already closed PRs

[danicheg]

I noticed in several orgs that "Superseded by" comments are being propagated to already closed PRs:
http4s/http4s-grpc#213
typelevel/vault#632

Haven't seen this before, can this be a regression or something?

[mzuehlke]

from the logs:

  2026-01-26 12:27:51,810 INFO  ──────────── Steward typelevel/vault ────────────
  2026-01-26 12:27:51,810 INFO  Check cache of typelevel/vault
  2026-01-26 12:27:52,153 INFO  Find updates for typelevel/vault
...
  2026-01-26 12:27:52,171 INFO  Found 27 updates:
    org.scala-sbt:sbt : 1.12.0 -> 1.12.1
  2026-01-26 12:27:52,172 INFO  typelevel/vault is outdated:
    new version: org.scala-sbt:(scripted-plugin, scripted-plugin_2.12) : 1.12.0 -> 1.12.1
    new version: org.scala-sbt:sbt : 1.12.0 -> 1.12.1
  2026-01-26 12:27:52,172 INFO  Nurture typelevel/vault
  2026-01-26 12:27:52,172 INFO  Clone typelevel/vault
  2026-01-26 12:27:52,436 INFO  Found 1 update:
    org.scala-sbt:{sbt, (scripted-plugin, scripted-plugin_2.12)} : 1.12.0 -> 1.12.1
  2026-01-26 12:27:52,439 INFO  Process update org.scala-sbt:{sbt, (scripted-plugin, scripted-plugin_2.12)} : 1.12.0 -> 1.12.1
  2026-01-26 12:27:52,557 INFO  Create branch update/sbt-1.12.1
  2026-01-26 12:27:53,309 INFO  Executing post-update hook for org.scala-sbt:sbt with command 'sbt githubWorkflowGenerate'
  2026-01-26 12:28:08,137 INFO  Push 1 commit(s)
  2026-01-26 12:28:08,619 INFO  Create PR update/sbt-1.12.1
  2026-01-26 12:28:09,621 INFO  Created PR https://github.com/typelevel/vault/pull/636
  2026-01-26 12:28:09,626 INFO  Closing obsolete PR https://github.com/typelevel/vault/pull/614 for org.scala-sbt:{sbt, (scripted-plugin, scripted-plugin_2.12)} : 1.11.5 -> 1.11.6
  2026-01-26 12:28:10,592 INFO  Closing obsolete PR https://github.com/typelevel/vault/pull/617 for org.scala-sbt:{sbt, (scripted-plugin, scripted-plugin_2.12)} : 1.11.6 -> 1.11.7
  2026-01-26 12:28:11,700 INFO  Closing obsolete PR https://github.com/typelevel/vault/pull/632 for org.scala-sbt:{sbt, (scripted-plugin, scripted-plugin_2.12)} : 1.11.7 -> 1.12.0
  2026-01-26 12:28:12,854 INFO  ──────────── Total time: Steward typelevel/vault: 21s 44ms ────────────

[mzuehlke]

Likely the state of the PR hadn't been updated in the PullRequestRepository correctly.
Maybe we could double check, if the the "old" PR is still open before writing the comment and closing it.

[mzuehlke]

Could this be an unwanted side effect of #3793 @rtyley

[danicheg]

#3793

I haven't seen this before Jan 23rd, so it might be related

[rtyley]

Could this be an unwanted side effect of #3793 @rtyley

It's a fair question, but the new supersedes() method added by #3793 is only used in one place, where it's guarded by state === PullRequestState.Open:

scala-steward/modules/core/src/main/scala/org/scalasteward/core/nurture/PullRequestRepository.scala

Line 74 in ab5199e

if state === PullRequestState.Open && update.supersedes(u) =>

...so any problems in supersedes() should only affect PRs that PullRequestRepository says are open. As http4s/http4s-grpc#213 & typelevel/vault#632 were already merged, the problem must be more that PullRequestRepository thought they were still open...

2026-01-26 12:28:11,700 INFO  Closing obsolete PR https://github.com/typelevel/vault/pull/632 for org.scala-sbt:{sbt, (scripted-plugin, scripted-plugin_2.12)} : 1.11.7 -> 1.12.0

The most recent Scala Steward release, v0.37.1, contained 3 other refactorings as well as #3793, it feels like the cause of this regression must be one of them, tho' I'm not sure which yet.

[danicheg]

No claims, folks. We shouldn't take this as finger-pointing or anything like that 🙏🏻

[rtyley]

No claims, folks. We shouldn't take this as finger-pointing or anything like that 🙏🏻

I concur! I did feel fairly safe in pointing to the other 3 refactorings, as I authored all of them, so I didn't feel like I was in danger of casting aspersions on anyone else 😄

• Remove legacy Update decoders (drop support for old PR caches) #3785
• Pre-PR #3787 - small tweaks #3788
• Refactor: Separate modelling of candidate newerVersions from Updates #3787

[rtyley]

I've been trying to understand the mechanism by which Scala Steward updates its data on the open/closed status of PRs when they are merged by the external action of a user - ie, if a PR is has already been merged by someone else, what part of Scala Steward knows that so that it doesn't interact further with that PR?

Assuming that closing obsolete PRs (originally introduced with #1667 in October 2020) with a comment (introduced with #1674 shortly after) was all working back in v0.37.0 (released October 2025, about 3 months ago), I've been examining the code at v0.37.0.

In order to get current PR open/closed state, Scala Steward must call something in the ForgeApiAlg that returns information on PRs. There are only 3 methods of ForgeApiAlg that return PR information (PullRequestOut), so far as I can see:

scala-steward/modules/core/src/main/scala/org/scalasteward/core/forge/ForgeApiAlg.scala

Lines 28 to 38 in 61ad654

	def createPullRequest(repo: Repo, data: NewPullRequestData): F[PullRequestOut]
	def updatePullRequest(number: PullRequestNumber, repo: Repo, data: NewPullRequestData): F[Unit]
	def closePullRequest(repo: Repo, number: PullRequestNumber): F[PullRequestOut]
	def getBranch(repo: Repo, branch: Branch): F[BranchOut]
	def getRepo(repo: Repo): F[RepoOut]
	def listPullRequests(repo: Repo, head: String, base: Branch): F[List[PullRequestOut]]

Of these, only listPullRequests() seems pertinent to discovering whether an existing PR has been merged by someone else - and that's called in only 1 place, within NurtureAlg.processUpdate():

scala-steward/modules/core/src/main/scala/org/scalasteward/core/nurture/NurtureAlg.scala

Lines 96 to 97 in 61ad654

	head = config.tpe.pullRequestHeadFor(data.fork, data.updateBranch)
	pullRequests <- forgeApiAlg.listPullRequests(data.repo, head, data.baseBranch)

This is searching the GitHub API for existing PRs that use a branch (head) matching the name that we would use for the proposed update - for example, when Scala Steward was considering making typelevel/vault#636, updating sbt to 1.12.1, it would have been searching for update/sbt-1.12.1, and the search would not have returned typelevel/vault#632, which had branch name update/sbt-1.12.0.

[rtyley]

Ah, I no longer think this is a regression - I believe instead that it's a bug that's existed ever since the feature was introduced by #1667 & #1674 in late 2020. Trying to figure out where the regression had happened was sending me crazy, I'm glad it's just never worked!

To check whether this was a regression or not, I searched in the typelevel org for Scala Steward commenting "Superseded by" from 2021 onwards on merged PRs. This found many examples of Scala Steward making the comment on PRs that were already merged, here's a sample demonstrating that the issue has existed over time:

• Update sbt-tpolecat to 0.1.15 typelevel/monoids#126
• Update sbt to 1.8.3 typelevel/sbt-typelevel#507
• Update circe-core, circe-generic, ... to 0.14.8 typelevel/doobie#2053
• Update scala-library to 2.13.17 typelevel/monoids#477

Likely the state of the PR hadn't been updated in the PullRequestRepository correctly.
Maybe we could double check, if the the "old" PR is still open before writing the comment and closing it.

Yep, I think your assessment here is right, @mzuehlke !

[mzuehlke]

When looking at the current code I was suspecting something very similar. Great that you came to the same conclusion 😄

[mkurz]

Something definitely is wrong here (and needs fixing).

I woke up today, having 600 GitHub notifications in my inbox,, basically 98% just scala steward commenting "Superseded by..." on long merged PRs. This never happened. Until now scala steward only commented on open PRs (which it closed then in favor for the new one).

I mean look at this, I get comments on each patch release, not just the one with the latest version (which was merged already):

So you say it seems that was a bug before already, possible, I didn't look at the code, but somehow that bug wasn't triggered before but gets triggered now(?)

[mkurz]

And as I type here, scala steward keeps commenting...

[mzuehlke]

On The Scala Steward Repo it just tagged a LOT of old sbt releases:

• Update sbt, scripted-plugin to 1.12.1 #3801

[tgodzik]

Should we disable this functionality altogether while it's investigated?

[rtyley]

Ok, fair enough - the problem has definitely got significantly worse. As I mentioned in #3797 (comment), the feature of Scala Steward commenting "Superseded by..." on PRs has always had a bug that unpredictably allowed it do that on closed PRs, because the state it was reading from its file-based cache here would be stale & incorrect:

scala-steward/modules/core/src/main/scala/org/scalasteward/core/nurture/PullRequestRepository.scala

Line 74 in ab5199e

if state === PullRequestState.Open && update.supersedes(u) =>

...however, the problem has got worse because the logic on the right-hand of that expression has changed and is now much more likely to fire - the logic of supersedes() on the RHS is correct, but it's exposing the problem with the LHS much more often.

As @mzuehlke suggested, checking the 'open' status of PRs before commenting on them would fix this problem, and I'll work on that, it'll involve a bit of thought.

In the meantime:

• If you control your Scala Steward instance, you can revert to 0.37.0 to get back to the old logic, which did have this problem, but much less frequently
• As @tgodzik suggested, I'll open a quick PR (Temporarily stop commenting on superseded PRs due to bug #3797 #3802) to disable the commenting altogether, and assuming there are no objections, I'll release that as 0.37.2, which will be automatically picked up by Scala Steward instances that use the latest released version.