[BUG] Runtime crash when serializing AsyncApi without mandatory fields

[Varadraj75]

Describe the bug.

The AsyncApi DSL allows creating an instance without initializing mandatory fields such as info and channels.
This leads to a runtime crash during JSON serialization, instead of failing fast with a clear validation error.

The issue occurs because these mandatory fields are defined using lateinit, which bypasses compile-time checks and throws an exception only when accessed at runtime.

Expected behavior

• The AsyncApi DSL should fail fast when mandatory fields such as info and channels are not defined.
• A clear, descriptive validation error should be thrown, indicating which required fields are missing.
• The error should occur before or during DSL validation, not later during JSON serialization.
• Runtime crashes caused by lateinit access should be avoided.
• Users should not be able to generate or serialize an invalid AsyncAPI document.

Screenshots

Failing test output when running mvn -pl kotlin-asyncapi-core test:

This shows a runtime failure caused by accessing an uninitialized lateinit property
(AsyncApi["info"]) during Jackson serialisation.

How to Reproduce

1. Clone the repository:

   git clone https://github.com/asyncapi/kotlin-asyncapi.git
   cd kotlin-asyncapi

2. Add code that creates an AsyncApi instance without setting required fields and serialise it:

   val asyncApi = AsyncApi()
   ObjectMapper().writeValueAsString(asyncApi)

3. Run the core module tests:

   mvn -pl kotlin-asyncapi-core test

4. The build fails with:

   lateinit property info has not been initialized
   
   

🖥️ Device Information [optional]

• Operating System (OS): macOS
• Browser: Google Chrome
• Browser Version: 144.0.0.0

👀 Have you checked for similar open issues?

• I checked and didn't find similar issue

🏢 Have you read the Contributing Guidelines?

• I have read the Contributing Guidelines

Are you willing to work on this issue ?

Yes I am willing to submit a PR!

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[Varadraj75]

@lorenzsimon
Could you please take a look at this issue when you have a moment?
I’ve reproduced it locally and shared detailed steps above. Thanks!

[lorenzsimon]

Thanks for the bug report @Varadraj75. As far as I know Kotlin does not provide compiler features to require a function to be called in a specific scope. This would be needed to check the mandatory fields in the DSL. The only option to fix the issue without breaking backwards compatibility is to check the constraints at runtime.

Something like this:

inline fun <T> T.checkInitialized(
    vararg props: KProperty0<*>
): T = also {
    val missing = props
        .filterNot { it.isInitialized }
        .map { it.name }

    check(missing.isEmpty()) {
        "Missing required properties: ${missing.joinToString()}"
    }
}

inline fun asyncApi(build: AsyncApi.() -> Unit): AsyncApi =
    AsyncApi()
        .apply(build)
        .checkInitialized(
            it::info,
            it::channels
        )

I am quite busy right now but will have a look once I find time. This would be also a good problem to solve as a first issue for new contributors.

[Varadraj75]

Thanks for the detailed explanation @lorenzsimon — that makes sense.

I agree that runtime validation is the safest option here without breaking backward compatibility, and the checkInitialized approach you outlined looks clean and expressive.

If you’re okay with it, I can take this up and work on implementing runtime validation for mandatory fields (info, channels) along these lines, along with tests to cover the failure case and ensure a clear error message.

Please let me know if you have any preferences on where this validation should live (e.g. DSL entry point vs serialization boundary). Thanks!

[lorenzsimon]

@Varadraj75 yes sure. Go ahead 👍