grails.serverURL (and other grails.* keys) in rundeck-config.groovy silently ignored in 6.0.1, even though other custom keys in the same file load correctly #10416

Rundeck version: 6.0.1.20260715-1 (upgraded from 5.19.0.20260202-1)
Java: OpenJDK 25.0.4 (also reproduced on OpenJDK 17)
Install: Debian package, MariaDB backend, config supplied via -Drundeck.config.location pointing at a custom rundeck-config.groovy

Summary

After upgrading from 5.19 to 6.0.1, every job execution fails immediately with IllegalStateException: Attribute absolute='true' specified but no grails.serverURL set in Config, even though grails.serverURL is set in the config file referenced by -Drundeck.config.location. Other custom keys in that same file (dataSource.*, rundeck.*, quartz.*) load and work correctly — only the grails.*-namespaced keys (grails.serverURL, grails.mail.default.from) are not picked up. Converting the exact same settings to the flat .properties format resolves the issue completely with no other change.

Steps to reproduce

1. Use a rundeck-config.groovy (Groovy/ConfigSlurper format) as the config file, e.g.:

   rdeck.base = "/var/lib/rundeck"
   dataSource {
     url = "jdbc:mysql://host:3307/rundeck"
     driverClassName = "org.mariadb.jdbc.Driver"
     username = "rundeckuser"
     password = "..."
   }
   grails.serverURL = "https://rundeck.example.com"
   rundeck.projectsStorageType = "db"

2. Point RDECK_CONFIG_FILE (/etc/default/rundeckd) and confirm via the running process (-Drundeck.config.location=...) that it resolves to this exact file.
3. Start Rundeck 6.0.1 and let any job execute.

Actual behavior

[...] ERROR services.ExecutionService [quartzScheduler_Worker-...] - Failed while starting execution: <id>
java.lang.IllegalStateException: Attribute absolute='true' specified but no grails.serverURL set in Config
	at org.grails.web.mapping.DefaultLinkGenerator.handleAbsolute(DefaultLinkGenerator.groovy:407)
	at org.grails.web.mapping.DefaultLinkGenerator.link(DefaultLinkGenerator.groovy:281)
	at org.grails.web.mapping.CachingLinkGenerator.link(CachingLinkGenerator.java:77)
	at rundeck.services.ExecutionService.generateServerURL(ExecutionService.groovy:1160)
	at rundeck.services.ExecutionService.exportContextForExecution(ExecutionService.groovy:1132)
	at rundeck.services.ExecutionService.$tt__executeAsyncBegin(ExecutionService.groovy:1214)
	at rundeck.quartzjobs.ExecutionJob.executeCommand(ExecutionJob.groovy:420)

Every single execution fails this way from the very first second after startup — 100% reproducible, not intermittent. The same exception also breaks NotificationService/LogFileStorageService wherever an absolute link needs to be generated, so email/Slack failure notifications fail too as a side effect.

We confirmed via /proc/<pid>/cmdline that the JVM was in fact started with -Drundeck.config.location=/etc/rundeck/rundeck-config.groovy, and confirmed the file does contain grails.serverURL, ruling out a simple "wrong file path" misconfiguration. We also confirmed dataSource, quartz.threadPool.threadCount, and rundeck.storage.provider.* from that same file were correctly in effect (DB connections worked, quartz threadpool sized correctly, project storage worked) — so the file is being read; only the grails.* keys are dropped.

Expected behavior

grails.serverURL set in the referenced config file (regardless of .properties vs .groovy format) should be honored, as it was under 5.19 with the identical file.

Fix that resolved it

Converting the same content to flat rundeck-config.properties syntax (no nested Groovy blocks, e.g. dataSource.url=... instead of dataSource { url = ... }, and plain grails.serverURL=https://...) and pointing rundeck.config.location at that file fixed the issue immediately and completely — confirmed over an extended run with zero recurrences and hundreds of successful executions.

Suspected root cause

Not confirmed at the source-code level (unlike the companion NotificationService bug we filed separately in #10415), but strongly indicated by behavior: this looks like a regression in how the Grails 7 / Spring Boot 3 rewrite in 6.0.0 merges a custom .groovy-format config file's grails.*-namespaced (framework-reserved) properties into the runtime Environment/Grails Config used by early-initialized beans (e.g. LinkGenerator), versus plain non-namespaced custom keys, which do merge correctly regardless of format. This matches the pattern of a much older, ostensibly-fixed issue in the Rundeck tracker (#4083 — "Authentication fails when using groovy configuration file format", where any grails block in a .groovy config file broke things back in 3.0.x) — suggesting the same class of .groovy + grails.* config-merging bug has resurfaced with the Grails 7 upgrade.

Impact

Total outage of job execution immediately after upgrading to 6.0.1, for any installation using the (previously fully-supported) .groovy config file format with grails.serverURL set in it. No warning or migration note in the 6.0.0 release notes about this.

Suggested next step for maintainers

Reproduce with a minimal rundeck-config.groovy containing only rdeck.base and grails.serverURL, and trace how rundeck.config.location-supplied .groovy files are merged into the Spring Environment/Grails Config in 6.0.x, specifically whether grails.*-prefixed keys are filtered out or merged at a point too late for LinkGenerator (and similar early-initialized beans) to see them.