How a Misused {} Lambda Triggered a Massive FastJson Crash in a Kotlin‑Java Service

Project Background

Our service is a mixed Kotlin‑Java (with occasional Groovy) codebase. Java is well‑supported in Alibaba's ecosystem, while Kotlin offers concise syntax and coroutines but has limited tooling support.

Java: mature, widely used.

Kotlin: fewer lines, coroutine support, but tooling gaps.

Groovy: rarely used, consulted via AI when needed.

Problem Symptoms

During a pre‑release test, a large number of deserialization errors appeared, causing most FastJson‑related request paths to fail. The issue resurfaced after a redeploy, indicating a persistent problem.

Investigation Process

1. Suspecting FastJson version

Checked pom.xml for version mismatches and found a transitive dependency pulling in fastjson:1.2.68_noneautotype via rass-sdk-core, while the project standard is 1.2.83_noneautotype. Removing that package temporarily stopped the errors, but they returned later.

2. Suspecting Kotlin‑related dependencies

Verified kotlin‑reflect is correctly included. Explored the possibility that a data class field caused the failure.

3. Searching for similar cases

Found a Juejin article describing a comparable FastJson‑Kotlin issue involving a static volatile flag kotlin_error. The article suggested the root cause is a static flag being set to true after a failed constructor lookup.

4. Pinpointing the error location

In QuestionCardProxyApi (line 228) the field resumeBody was assigned {}. In Kotlin, {} is interpreted as a lambda of type () -> Unit, not an empty object.

5. Understanding the impact

The lambda caused FastJson to fail parsing the field, which set the static volatile kotlin_error flag to true. Subsequent deserialization attempts returned null, leading to default constructor not found exceptions across the service.

Root Cause

The mistaken use of {} as a placeholder for an empty object introduced a lambda that corrupted the global kotlin_error flag, breaking FastJson’s handling of Kotlin data classes.

Solution & Code Example

Replace the lambda with a proper empty object or a nullable field. The following test reproduces the issue and works with FastJson 2.0.53:

class KotlinErrorTest {
    @Test
    fun testFastJson() {
        val jsonObj = JSONObject().apply {
            this["accessorUuid"] = "accessorUuid"
            this["orgId"] = 4343L
            this["resumeTaskId"] = "resumeUrl"
            this["resumeBody"] = {}
        }
        // This toJSONString corrupts kotlin_error
        JSON.toJSONString(jsonObj)

        val testA = A("1")
        val strA = JSON.toJSONString(testA)
        val objA = JSON.parseObject(strA, A::class.java)
        println(objA)
    }

    data class A(val a: String)

    @Test
    fun testLambda() {
        val x = { s: String -> s + "000" }
        val y = x("111")
        println(y)
    }
}

Summary & Reflection

The bug took two days to resolve and highlighted several lessons:

Mixed‑language projects require careful handling of language‑specific syntax, especially when assigning values.

Feature flags (gray releases) prevented the bug from affecting production traffic.

FastJson has many known vulnerabilities; always stay vigilant.

Debugging complex issues often involves tracing static state changes across the codebase.