Spring Boot runner failure: reject startup instead of accepting unsafe settings

Make the rejected state visible

The checked runner throws for an unsafe batch setting. The test asserts that the Boot launch raises an exception with that cause instead of returning a healthy context to its caller. A production runner should include a bounded, actionable error and avoid printing sensitive configuration values.

The application context may have already initialized other components before a runner executes. A failed run is therefore not proof that no socket ever opened or that no external side effect occurred. Keep irreversible work out of startup runners; validate configuration before starting work where possible. Configuration validation and runner argument parsing are the adjacent contracts.

Decide what must stop the process

A missing required schema or credential can justify failing startup. A transient downstream outage may be better represented by readiness DOWN while the process remains live. The choice belongs to the service's recovery design, not to a blanket catch-and-continue block.

Checked code

@Bean ApplicationRunner rejectUnsafeSettings() {
    return arguments -> {
        throw new IllegalStateException("unsafe batch setting");
    };
}

Verification boundary

The Maven source kit passes LifecycleAndMvcDispatchContractTest.failingApplicationRunnerPreventsSuccessfulBootStartup on its local Spring Boot 4 and Java 21 fixture.

Cost and ownership

The fixture tests one non-web context and its thrown cause. It does not establish how an ingress routes traffic during web-server startup, whether shutdown hooks finish external cleanup, or how a platform restarts the process after failure.

Common Mistakes

• Do not swallow a required startup validation failure and report ready.
• Do not assume a failed runner means no external effect occurred earlier.
• Do not log secret values in startup exceptions.

Read next

Spring Boot ApplicationRunner and CommandLineRunner: parse arguments at startup, Spring Boot configuration validation: reject an unusable relay before work starts, Spring readiness: report an unavailable dependency without forcing liveness failure, Spring readiness during termination: stop routing before stopping dependencies.