Regression: SRCFG00011: Could not expand value exception

[knutwannheden]

Describe the bug

There appears to be a regression in Quarkus 2.12.0.CR1 in the area of SmallRye Config.

I have a simple application which only uses quarkus-resteasy-reactive and quarkus-security and the following application.properties file:

quarkus.http.auth.permission.quarkus.paths=${quarkus.http.non-application-root-path}/*
quarkus.http.auth.permission.quarkus.policy=devops
quarkus.http.auth.policy.devops.roles-allowed=DEVOPS

When starting up the application it fails with an exception with the following root cause:

Caused by: java.util.NoSuchElementException: SRCFG00011: Could not expand value quarkus.http.non-application-root-path in property quarkus.http.auth.permission.quarkus.paths
	at io.smallrye.config.ExpressionConfigSourceInterceptor$1.accept(ExpressionConfigSourceInterceptor.java:68)
	at io.smallrye.config.ExpressionConfigSourceInterceptor$1.accept(ExpressionConfigSourceInterceptor.java:58)
	at io.smallrye.common.expression.ExpressionNode.emit(ExpressionNode.java:22)
	at io.smallrye.common.expression.CompositeNode.emit(CompositeNode.java:22)
	at io.smallrye.common.expression.Expression.evaluateException(Expression.java:56)
	at io.smallrye.common.expression.Expression.evaluate(Expression.java:70)
	at io.smallrye.config.ExpressionConfigSourceInterceptor.getValue(ExpressionConfigSourceInterceptor.java:58)
	at io.smallrye.config.ExpressionConfigSourceInterceptor.getValue(ExpressionConfigSourceInterceptor.java:38)
	at io.smallrye.config.SmallRyeConfigSourceInterceptorContext.proceed(SmallRyeConfigSourceInterceptorContext.java:20)
	at io.smallrye.config.FallbackConfigSourceInterceptor.getValue(FallbackConfigSourceInterceptor.java:24)
	at io.smallrye.config.SmallRyeConfigSourceInterceptorContext.proceed(SmallRyeConfigSourceInterceptorContext.java:20)
	at io.smallrye.config.PropertyNamesConfigSourceInterceptor.getValue(PropertyNamesConfigSourceInterceptor.java:17)
	at io.smallrye.config.SmallRyeConfigSourceInterceptorContext.proceed(SmallRyeConfigSourceInterceptorContext.java:20)
	at io.smallrye.config.SmallRyeConfig.getConfigValue(SmallRyeConfig.java:307)
	at io.quarkus.runtime.configuration.ConfigRecorder.handleConfigChange(ConfigRecorder.java:40)
	at io.quarkus.deployment.steps.ConfigGenerationBuildStep$checkForBuildTimeConfigChange1532146938.deploy_4(Unknown Source)
	at io.quarkus.deployment.steps.ConfigGenerationBuildStep$checkForBuildTimeConfigChange1532146938.deploy(Unknown Source)
	... 52 more

So somehow the value in the quarkus.http.auth.permission.quarkus.paths=${quarkus.http.non-application-root-path}/* cannot be expanded. In all earlier versions of Quarkus this worked.

Expected behavior

It seems like this should be allowed.

Actual behavior

Exception thrown at startup (see issue description).

How to Reproduce?

Reproduce:

1. Download and extract code-with-quarkus.zip
2. Run mvn verify or mvn quarkus:dev
3. See logged exception

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.12.0.CR1

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

No response

Additional information

No response

[knutwannheden]

/cc @radcortez

[gsmet]

Roberto is on PTO for now so this will have to wait for 2.12.1.Final.

[knutwannheden]

I assume the regression is related to the recent PR #26802. But this also got me thinking if a properties file (like application.properties or microprofile-config.properties) is allowed to refer to a build-time property (using property expansion) in the value for a runtime property. I think this should definitely work in the case of build-time properties defined in the scope of a @ConfigRoot(phase = BUILD_AND_RUN_TIME_FIXED) root, but what about roots with @ConfigRoot(phase = BUILD_TIME)? I think even the latter should be allowed, since the properties file was already provided at build-time, but that would also require some processing at build-time, which I don't know if Quarkus already does or not.

[gsmet]

@knutwannheden could you have a look at #27576 ?

[radcortez]

I think this should definitely work in the case of build-time properties defined in the scope of a @ConfigRoot(phase = BUILD_AND_RUN_TIME_FIXED) root,

This works since we need to resolve the value for extensions, and we need to write the resolved value for runtime to make sure it is not changed.

but what about roots with @ConfigRoot(phase = BUILD_TIME)? I think even the latter should be allowed, since the properties file was already provided at build-time, but that would also require some processing at build-time, which I don't know if Quarkus already does or not.

We don't support this, and I think it doesn't make sense. If we allow build time properties to be used to expand runtime properties, then there will be no difference between both, and users would be able to reference either. This will probably confuse users on why build time properties changes do not have any effect.

[knutwannheden]

@knutwannheden could you have a look at #27576 ?

I will take a look and report back tomorrow.

We don't support this, and I think it doesn't make sense. If we allow build time properties to be used to expand runtime properties, then there will be no difference between both, and users would be able to reference either. This will probably confuse users on why build time properties changes do not have any effect.

There would still be a small difference: If a runtime property value is already supplied at build-time, then it would be able to refer to build-time properties. If the value is supplied at run-time, then not. But I agree that this may be confusing and I have until now never run into the need for this feature.

[knutwannheden]

@gsmet I quickly tested my reproducer against the branch and I can confirm that the PR fixes the bug.