KTOR-6610: feat: add debug log of ConfigLoader when server starts

[Ryuheeeei]

Subsystem
ktor-server-core (io.ktor.server.config)

Motivation
This PR fixes KTOR-6610. Related to KTOR-8992, too.
Adding debug log when server starts will reveal which configuration file is used.
If configuration is inappropriate, it gives following error as is.

Exception in thread "main" java.lang.IllegalArgumentException: Neither port nor sslPort specified. Use command line options -port/-sslPort or configure connectors in application.conf
        at io.ktor.server.engine.CommandLineKt.CommandLineConfig(CommandLine.kt:74)
        at io.ktor.server.netty.EngineMain.createServer(EngineMain.kt:39)
        at io.ktor.server.netty.EngineMain.main(EngineMain.kt:24)

However, adding debug log, the output is like:

2025-10-22 17:15:38.848 [main] DEBUG io.ktor.server.config.ConfigLoader - Trying ConfigLoader: YamlConfigLoader
2025-10-22 17:15:38.858 [main] DEBUG io.ktor.server.config.ConfigLoader - No configuration found, using empty MapApplicationConfig
Exception in thread "main" java.lang.IllegalArgumentException: Neither port nor sslPort specified. Use command line options -port/-sslPort or configure connectors in application.conf
        at io.ktor.server.engine.CommandLineKt.CommandLineConfig(CommandLine.kt:74)
        at io.ktor.server.netty.EngineMain.createServer(EngineMain.kt:39)
        at io.ktor.server.netty.EngineMain.main(EngineMain.kt:24)

Thus we can realize the ConfigLoader is not HoconConfigLoader, but YamlConfigLoader because we include ktor-server-config-yaml on the classpath.

Solution
Using KtorSimpleLogger and add debug log to ConfigLoader companion object.
I referred https://github.com/ktorio/ktor/blob/main/ktor-server/ktor-server-core/jvm/src/io/ktor/server/http/content/ETagProvider.kt as code style.

output example

Hocon

2025-10-22 17:27:12.861 [main] DEBUG io.ktor.server.config.ConfigLoader - Trying ConfigLoader: HoconConfigLoader
2025-10-22 17:27:12.896 [main] DEBUG io.ktor.server.config.ConfigLoader - Configuration loaded successfully using HoconConfigLoader from path: application_custom.conf

Yaml

2025-10-22 15:59:50.016 [main] DEBUG io.ktor.server.config.ConfigLoader - Trying ConfigLoader: YamlConfigLoader
2025-10-22 15:59:50.058 [main] DEBUG io.ktor.server.config.ConfigLoader - Configuration loaded successfully using YamlConfigLoader from path: application_custom.yaml

No configuration

2025-10-22 17:15:38.848 [main] DEBUG io.ktor.server.config.ConfigLoader - Trying ConfigLoader: YamlConfigLoader
2025-10-22 17:15:38.858 [main] DEBUG io.ktor.server.config.ConfigLoader - No configuration found, using empty MapApplicationConfig

[coderabbitai]

Walkthrough

Added debug logging to ConfigLoaders.kt in the load() and loadDefault() methods. Imported logging utilities and created a private logger instance. Logs indicate which ConfigLoader is attempted, success/failure outcomes, and default configuration loading events. No public API modifications.

Changes

Cohort / File(s)	Change Summary
Logging Enhancements ktor-server/ktor-server-core/common/src/io/ktor/server/config/ConfigLoaders.kt	Added private logger instance and debug logging at key points in ConfigLoader.load() and loadDefault() methods to track configuration loading attempts, outcomes, and default path resolution. Logging is additive; no public API changes.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The PR title "KTOR-6610: feat: add debug log of ConfigLoader when server starts" is specific and directly related to the main change in the changeset. It clearly conveys that the PR adds debug logging functionality to ConfigLoader during server startup, which aligns perfectly with the raw summary showing logging was added at key points in ConfigLoader.load() and loadDefault() methods. The title is concise, includes the issue reference, and is clear enough for teammates to understand the primary change without ambiguity.
Description Check	✅ Passed	The PR description fully follows the required template with all three sections well-completed. The Subsystem section clearly identifies the affected module (ktor-server-core, io.ktor.server.config). The Motivation section is comprehensive, referencing relevant tickets (KTOR-6610 and KTOR-8992), explaining the problem with concrete examples of error messages and how debug logs would help diagnose configuration issues. The Solution section describes the implementation approach using KtorSimpleLogger with a code style reference, and includes practical output examples showing log messages for different scenarios (Hocon, Yaml, and no configuration cases).

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

ktor-server/ktor-server-core/common/src/io/ktor/server/config/ConfigLoaders.kt (1)

63-70: Consider clarifying the log message for null paths.

When path is null (which can occur if loadDefault() returns null and a loader subsequently succeeds with a null path), line 67 logs "from path: null", which may be confusing.

Consider making the message more explicit:

                 if (config != null) {
-                    logger.debug("Configuration loaded successfully using ${loader::class.simpleName} from path: $path")
+                    val pathInfo = path?.let { "from path: $it" } ?: "with null path (fallback)"
+                    logger.debug("Configuration loaded successfully using ${loader::class.simpleName} $pathInfo")
                     return config
                 }

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 21ed049 and 9f873b5.

📒 Files selected for processing (1)

• ktor-server/ktor-server-core/common/src/io/ktor/server/config/ConfigLoaders.kt (2 hunks)

🧰 Additional context used

📓 Path-based instructions (2)

**/*.{kt,kts}

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.{kt,kts}: Follow Kotlin official style guide for all Kotlin source and build scripts
Use star imports for io.ktor.* packages
Max line length is 120 characters
Indent with 4 spaces in Kotlin code
Include a copyright header in new Kotlin files

Files:

• ktor-server/ktor-server-core/common/src/io/ktor/server/config/ConfigLoaders.kt

**/*.kt

📄 CodeRabbit inference engine (CLAUDE.md)

**/*.kt: Document all public Kotlin APIs, including parameters, return types, and exceptions
Annotate internal APIs with @internalapi
Follow Kotlin error-handling conventions and use specific Ktor exceptions

Files:

• ktor-server/ktor-server-core/common/src/io/ktor/server/config/ConfigLoaders.kt

🔇 Additional comments (5)

ktor-server/ktor-server-core/common/src/io/ktor/server/config/ConfigLoaders.kt (5)

7-8: LGTM: Import follows coding guidelines.

The star import for io.ktor.* packages aligns with the project's coding guidelines and properly imports the logging utilities needed for the debug functionality.

---

11-11: LGTM: Logger instance properly initialized.

The private logger with a descriptive name is appropriate for this companion object's diagnostic logging needs.

---

57-61: LGTM: Default configuration loading logging is clear.

The debug log appropriately indicates when the default configuration path is being attempted, providing useful diagnostic information.

---

72-73: LGTM: Clear fallback logging.

The debug log appropriately indicates when no configuration is found and an empty MapApplicationConfig is used as a fallback.

---

76-90: LGTM: Comprehensive default configuration loading logs.

The nested logging structure clearly traces which default paths and loaders are being attempted, providing valuable diagnostic information. While this generates multiple debug messages in the nested loops, this is appropriate for debug-level logging and aligns with the PR's objective to reveal which ConfigLoader is used at server start.