Gary K
02/19/2026, 10:30 PMERROR i.m.r.Micronaut(handleStartupException):362 - Error starting Micronaut server: Bean definition [io.airbyte.server.apis.controllers.SourceDef
initionApiController] could not be loaded: Error instantiating bean of type [io.airbyte.commons.logging.LogClientManager]
Message: Use JsonReader.setStrictness(Strictness.LENIENT) to accept malformed JSON at line 1 column 2 path $kapa.ai
02/19/2026, 10:30 PMSourceDefinitionApiController bean failing to load, and LogClientManager instantiation error with a MalformedJsonException / JsonReader.setStrictness(Strictness.LENIENT) message) matches a known class of startup failures where Airbyte’s server can’t read some JSON-based configuration or log-related state correctly. [[zendesk issue](https://github.com/airbytehq/airbyte/issues/65088); [helm storage types](https://github.com/airbytehq/airbyte/issues/70352)] From the available information, there are two likely categories of root cause: 1. Malformed JSON in configuration or secrets In the Zendesk connector issue, the same MalformedJsonException appears when the server tries to parse invalid JSON (e.g., credentials not matching the expected schema). [[zendesk issue](https://github.com/airbytehq/airbyte/issues/65088)] In your case, because the failure is during LogClientManager bean creation, it suggests that some logging-related configuration (or a file it reads) is not valid JSON. 2. Storage / logging backend misconfiguration (S3 vs MinIO, paths, or env vars) There is a related class of issues where misconfigured storage/logging settings (especially S3 vs MinIO and inconsistent env var names) cause workers or server components to fail to start. [[worker not started](https://discuss.airbyte.io/t/3054); [helm storage types](https://github.com/airbytehq/airbyte/issues/70352)] In one case, the user only got things working after switching from S3 to the MinIO-based setup and fixing inconsistent S3-related env vars. [[worker not started](https://discuss.airbyte.io/t/3054)] Given what’s in the knowledge sources, here’s what you can concretely check: 1. Inspect the full stack trace and logs around LogClientManager - Look for any mention of a file path or URL right before the MalformedJsonException. - That will usually point to the JSON file or response that is malformed. 2. Verify logging / storage configuration - If you’re using S3 or another external storage for logs, double‑check all related env vars (for example, in similar issues users had to set multiple S3-related vars because of inconsistent naming). [[worker not started](https://discuss.airbyte.io/t/3054); [helm storage types](https://github.com/airbytehq/airbyte/issues/70352)] - Ensure any JSON values you pass via env vars or config maps (e.g., logging config) are valid JSON (no trailing commas, correct quoting, etc.). 3. Try a “known good” configuration - If you’re on Kubernetes/Helm and using S3 for logs or state, the forum example indicates that switching to the default MinIO-based setup allowed the system to start, confirming the issue was with S3-related configuration. [[worker not started](https://discuss.airbyte.io/t/3054)] - As a diagnostic step, you could temporarily revert to the default (local/MinIO) logging & storage configuration to see if the server starts cleanly. Because the knowledge sources don’t include a precise, step‑by‑step fix for this exact LogClientManager + MalformedJsonException combination, I can’t point to a single definitive change. The strongest evidence is that malformed or mismatched JSON in configuration (often tied to storage/logging backends like S3) is what triggers this class of startup failures. [[zendesk issue](https://github.com/airbytehq/airbyte/issues/65088); [worker not started](https://discuss.airbyte.io/t/3054)] If you can share: - How you’ve configured logging/storage (S3 vs MinIO, any custom logging config), and - The few lines before the exception in the server logs, I can help narrow down which specific config is most likely malformed.Gary K
02/19/2026, 10:39 PMkapa.ai
02/19/2026, 10:39 PM