upgrading from quarkus 3.5.3 to 3.6.0 java.lang.IllegalArgumentException: A case block for the string value already exist

[psini]

Describe the bug

after upgrading some of our project started to fail during the build with
[ERROR] [error]: Build step io.quarkus.arc.deployment.ArcProcessor#generateResources threw an exception: java.lang.IllegalStateException: java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: A case block for the string value [ka18bVEx2xqfTttwWUmpZsCNNWk] already exists
[ERROR] at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:858)
[ERROR] at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
[ERROR] at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2513)
[ERROR] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1538)
[ERROR] at java.base/java.lang.Thread.run(Thread.java:857)
[ERROR] at org.jboss.threads.JBossThread.run(JBossThread.java:501)
[ERROR] Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: A case block for the string value [ka18bVEx2xqfTttwWUmpZsCNNWk] already exists
[ERROR] at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
[ERROR] at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
[ERROR] at io.quarkus.arc.processor.BeanProcessor.generateResources(BeanProcessor.java:382)
[ERROR] at io.quarkus.arc.deployment.ArcProcessor.generateResources(ArcProcessor.java:519)
[ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[ERROR] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:568)
[ERROR] at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:849)
[ERROR] ... 6 more
[ERROR] Caused by: java.lang.IllegalArgumentException: A case block for the string value [ka18bVEx2xqfTttwWUmpZsCNNWk] already exists
[ERROR] at io.quarkus.gizmo.StringSwitchImpl.addCaseBlock(StringSwitchImpl.java:153)
[ERROR] at io.quarkus.gizmo.StringSwitchImpl.caseOf(StringSwitchImpl.java:123)
[ERROR] at io.quarkus.gizmo.StringSwitchImpl.caseOf(StringSwitchImpl.java:18)
[ERROR] at io.quarkus.arc.processor.ContextInstancesGenerator.implementComputeIfAbsent(ContextInstancesGenerator.java:260)
[ERROR] at io.quarkus.arc.processor.ContextInstancesGenerator.generate(ContextInstancesGenerator.java:85)
[ERROR] at io.quarkus.arc.processor.BeanProcessor$7.call(BeanProcessor.java:374)
[ERROR] at io.quarkus.arc.processor.BeanProcessor$7.call(BeanProcessor.java:369)
[ERROR] at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
[ERROR] ... 5 more

Expected behavior

the build is successful

Actual behavior

the build is broken

How to Reproduce?

No response

Output of uname -a or ver

Macos arm64

Output of java -version

openjdk version "17.0.9" 2023-10-17 IBM Semeru Runtime Open Edition 17.0.9.0 (build 17.0.9+9) Eclipse OpenJ9 VM 17.0.9.0 (build openj9-0.41.0, JRE 17 Mac OS X aarch64-64-Bit 20231017_458 (JIT enabled, AOT enabled) OpenJ9 - 461bf3c70 OMR - 5eee6ad9d JCL - 3699725139c based on jdk-17.0.9+9)

Quarkus version or git rev

3.6.0

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)

Additional information

No response

[psini]

If I use the following option quarkus.arc.optimize-contexts=false the build is successful

[quarkus-bot]

/cc @Ladicek (arc), @manovotn (arc), @mkouba (arc)

[Ladicek]

OK that is weird. Either we have one bean multiple times in the list of all beans, or we have multiple beans with the same ID. @psini I assume you don't have a small reproducer?

EDIT: or even a large reproducer :-)

[mkouba]

OK that is weird. Either we have one bean multiple times in the list of all beans, or we have multiple beans with the same ID. @psini I assume you don't have a small reproducer?

EDIT: or even a large reproducer :-)

Ladislav is right. We'll need a reproducer of any size for this one...

[psini]

I don't have a reproducer because the code i have is a closed source project and I cannot use it for a reproducer . How can I find which class is the one that create the issue ? In that way i could build a reproducer .

[mkouba]

I don't have a reproducer because the code i have is a closed source project and I cannot use it for a reproducer . How can I find which class is the one that create the issue ? In that way i could build a reproducer .

You can try to run your app in the dev mode (with context optimization disabled) and then HTTP GET /q/arc/beans

[Ladicek]

I added some debug printing that I believe would be useful for diagnosing this issue in my branch here: https://github.com/Ladicek/quarkus/commits/context-instances-debugging

@psini If you can build Quarkus from that branch:

git clone https://github.com/Ladicek/quarkus.git my-quarkus-clone
cd my-quarkus-clone
git checkout origin/context-instances-debugging
mvn -Dquickly -Dno-test-modules -T 1C

then switch your project to Quarkus 999-SNAPSHOT and build your application (mvn clean package -DskipTests), you should observe that the Quarkus Maven plugin produces output similar to:

[INFO] --- quarkus-maven-plugin:999-SNAPSHOT:build (default) @ conprop ---
[INFO] [!!!] === Generating `ContextInstances` class for scope jakarta.enterprise.context.ApplicationScoped, 4 bean(s) ===
[INFO] [!!!] QdZg1cXs34dPRiG8Uz7lyUDudlo -> 1 bean(s):
[INFO] [!!!] - CLASS bean [types=[io.smallrye.config.inject.ConfigProducer, java.lang.Object], qualifiers=[@Default, @Any], target=io.smallrye.config.inject.ConfigProducer]
[INFO] [!!!] N80A159oF8msb0BBZG1sW4wdTGk -> 1 bean(s):
[INFO] [!!!] - SYNTHETIC bean [types=[org.eclipse.microprofile.context.ManagedExecutor, java.lang.Object, io.smallrye.context.SmallRyeManagedExecutor], qualifiers=[@Default, @Any], target=n/a]
[INFO] [!!!] cAsQhMqDYUnGxT4AN4njjudQ50I -> 1 bean(s):
[INFO] [!!!] - SYNTHETIC bean [types=[java.util.concurrent.Executor, java.util.concurrent.ExecutorService, java.lang.Object, java.util.concurrent.ScheduledExecutorService], qualifiers=[@Default, @Any], target=n/a]
[INFO] [!!!] DXAgdn0Uq14IR-Udb4sr9S6ViFE -> 1 bean(s):
[INFO] [!!!] - CLASS bean [types=[cz.ladicek.quarkus.tiny.conprop.MyConPropUser, java.lang.Object], qualifiers=[@Default, @Any], target=cz.ladicek.quarkus.tiny.conprop.MyConPropUser]
[INFO] [!!!] === Generating `ContextInstances` class for scope jakarta.enterprise.context.RequestScoped, 1 bean(s) ===
[INFO] [!!!] H-Bvroair5uMN67Jf7Myxy4Lxo8 -> 1 bean(s):
[INFO] [!!!] - CLASS bean [types=[java.lang.Object, cz.ladicek.quarkus.tiny.conprop.MyReqData], qualifiers=[@Default, @Any], target=cz.ladicek.quarkus.tiny.conprop.MyReqData]
[INFO] [io.quarkus.deployment.QuarkusAugmentor] Quarkus augmentation completed in 545ms

The [!!!] part is interesting. It should contain at least one line that says [some bean ID] -> 2 bean(s), or more than 2. Could you please paste here those lines?

I'm afraid we don't have a better way to diagnose the problem. If you hit any roadblocks, feel free to ping me on the Quarkus Zulip.

[gsmet]

then switch your project to Quarkus 999-SNAPSHOT

when doing so, make sure you also update the groupId of the BOM and the plugin from io.quarkus.platform to io.quarkus.

[mkouba]

I added some debug printing that I believe would be useful for diagnosing this issue in my branch here: ...

I think that we should actually fail the build if multiple beans of the same identifier are found (for any reason) because it would break a lot of things anyway. Currently we only detect synthetic beans with non-unique identifiers.

For the record, a bean identifier for class-based beans is sha1 of toString() (which includes bean types + qualifiers + target class FQCN + target of declaringBean for producers) + deployment id.

[Ladicek]

I think that we should actually fail the build if multiple beans of the same identifier are found

That's a good point. If you don't beat me to it, I'll submit a PR tomorrow.

[psini]

Hi all i did as you asked but what i get is quite obscure to me, it seams the same class, but i checked and i'm sure there is only one copy of it, so it's not duplicated:
[INFO] [!!!] 9oN_LOho_5UeSuctOqg1jQwvIzY -> 2 bean(s):
[INFO] [!!!] - CLASS bean [types=[mypackage.util.IClearable, mypackage.context.threadlocal.ApiContextUtil, java.lang.Object], qualifiers=[@default, @Any], target=mypackage.context.threadlocal.ApiContextUtil]
[INFO] [!!!] - CLASS bean [types=[mypackage.util.IClearable, mypackage.context.threadlocal.ApiContextUtil, java.lang.Object], qualifiers=[@default, @Any], target=mypackage.context.threadlocal.ApiContextUtil]

How i can help you ? What's more it seams random because mypackage.util.IClearable is an interface and i have other 4 class that implements and another one has the same issue , instead the other two are clean.

Let me know

[Ladicek]

IClearable is not an issue here, that's one of the bean types of the ApiContextUtil bean. For some reason, that bean exists twice.

Since you're sure that there's only one copy of the mypackage.context.threadlocal.ApiContextUtil class, we'll have to figure out why is the class discovered twice. That really shouldn't happen.

I have to do the same thing for #37565, so I'll try to prepare some more debug logging.

[psini]

Yes i'm sure that the class is inside a common lib that's imported from all the other and doesn't exist anywhere else, it seams that is discovered twice but i don't know why .

[Ladicek]

Could you show the source code of that class? There might be something (most likely an annotation) that causes some Quarkus extension to register the class as an "additional" bean.

[psini]

It's trivial it starts as below and don't use any annotation inside it. We only manage a ThreadLocal variable
@ApplicationScoped
public final class ApiContextUtil implements IClearable {

[Ladicek]

OK, thanks. That class is certainly subject to bytecode transformation, as we need to make it non-final (to be able to generate a client proxy). Just out of curiosity, could you try removing the final keyword? I'm not holding my breath, but it would be interesting if that fixed the issue.

[Ladicek]

Also, we'll probably just have to adjust type discovery to skip already seen classes. There are many different reasons why one class can occur in the bean archive index multiple times and it isn't really practical to get all the "bean contributors" to agree.

[Ladicek]

@psini Could you also please check if your build log contains this message?

Detected a split package usage which is considered a bad practice and should be avoided. Following packages were detected in multiple archives:

If so, that might point to a reason.

[Ladicek]

we'll probably just have to adjust type discovery to skip already seen classes

I did this in #37565, so that will also fix this issue.

EDIT: and of course, the comment above is wrong in one technical aspect. This doesn't adjust type discovery, this adjusts bean discovery. Probably not interesting for most readers, but I felt compelled to correct myself :-)

[psini]

I compiled the main and tested it. It works flawless . Is there any chance that will be back ported to 3.6.x ?