Quarkus 3.15.2 Build Error: "String too large to record"

[can-ishk]

Describe the bug

Ciao, fellow members of the Quarkus community :)

I'm migrating from 2.16 to 3.15.2. We are using Quarkus with Kogito. While running the app in dev mode, a RuntimeException is thrown in BytecodeRecorderImpl.java.

 } else if (param instanceof String) {
            if (((String) param).length() > 65535) {
                throw new RuntimeException("String too large to record: " + param);
            }
            return new DeferredParameter() {
                @Override
                ResultHandle doLoad(MethodContext context, MethodCreator method, ResultHandle array) {
                    return method.load((String) param);
                }
            };

The content of the param is 69110 characters long and contains the following:

syntax = "proto3"; 
package org.kie.kogito.app; 
import "kogito-types.proto";

.
.
.
... some objects related to our business logic, including enums.
.
.
.

Is this a known issue? I came across this #39545 but it's supposed to be solved in 3.9.0.CR2.

I'd appreciate your thoughts.

Expected behavior

The build should succeed.

Actual behavior

2025-03-07 19:45:40,030 ERROR [io.qua.dep.dev.IsolatedDevModeMain] (main) Failed to start quarkus: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step io.quarkus.deployment.steps.MainClassBuildStep#build threw an exception: java.lang.RuntimeException: Failed to record call to method public io.quarkus.arc.runtime.BeanContainerListener io.quarkus.infinispan.client.runtime.InfinispanRecorder.configureInfinispan(java.util.Map)
	at io.quarkus.deployment.recording.BytecodeRecorderImpl.writeBytecode(BytecodeRecorderImpl.java:480)
	at io.quarkus.deployment.steps.MainClassBuildStep.writeRecordedBytecode(MainClassBuildStep.java:511)
	at io.quarkus.deployment.steps.MainClassBuildStep.build(MainClassBuildStep.java:211)
	at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:732)
	at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
	at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
	at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
	at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2516)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2495)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1521)
	at java.base/java.lang.Thread.run(Thread.java:840)
	at org.jboss.threads.JBossThread.run(JBossThread.java:483)
Caused by: java.lang.RuntimeException: String too large to record: 

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

RedHat\java-17-openjdk-17.0.11.0.9-1

Quarkus version or git rev

quarkus:3.15.2

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

Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
Maven home: C:\Program Files\JetBrains\IntelliJ IDEA 2024.2.3\plugins\maven\lib\maven3
Java version: 17.0.11, vendor: Red Hat, Inc., runtime: C:\Program Files\RedHat\java-17-openjdk-17.0.11.0.9-1
Default locale: en_IN, platform encoding: Cp1252
OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"

Additional information

No response

[gsmet]

So the specific issue in #39545 was fixed but this is a different issue with the same error message.

Kogito is apparently pushing a large String value to the recording infrastructure. It should probably be saved as a file in the jar instead.

@mariofusco do you know who we can ping to have a look at this issue?

[mariofusco]

@can-ishk Can you please provide a reproducer of this issue?

[geoand]

In any case, this isn't a Quarkus specific issue, but a Kogito issue (which as @gsmet says, shouldn't be trying to record such a large string)

[can-ishk]

hi guys @gsmet @mariofusco @geoand, thanks for responding. As you mentioned, it seems to be a Kogito issue. I'm currently evaluating and altering our logic to reduce the size of the string generated by Kogito, thereby preventing this error.

I'll post an update here soon.