When a plugin config key is invalid (e.g. after a schema migration), the gateway throws a hard config validation error and exits with code 1 instead of disabling only the affected plugin and continuing to start. This single config key error (the Brave search API key was at the old path) caused the entire gateway to be unavailable for 12.5 hours and 6,198 restart attempts (see related issue #60142).

• Plugin config errors → warn + disable plugin, do NOT exit

TL;DR

Modify the config validation layer to distinguish between fatal config errors and plugin config errors, allowing the gateway to start even if a plugin's config is invalid.

Guidance

• Review the config validation layer in src/config/ to identify where the hard exit is occurring and modify it to handle plugin config errors differently.
• Implement a warning and disable mechanism for plugin config errors, rather than exiting the entire gateway.
• Consider adding a startup summary to show which plugins were disabled due to config issues, to aid in debugging and monitoring.
• Verify the fix by intentionally introducing a plugin config error and checking that the gateway starts and logs a clear warning, while disabling the affected plugin.

Example

No specific code example is provided, as the issue does not include enough code context, but the fix would involve modifying the config validation logic to handle plugin config errors in a more granular way.

Notes

The suggested fix assumes that the config validation layer can be modified to distinguish between fatal and non-fatal config errors, and that the plugin loader can be updated to disable plugins with invalid config without exiting the gateway.

Recommendation

Apply a workaround by modifying the config validation layer to handle plugin config errors more robustly, as upgrading to a fixed version is not mentioned as an option in the issue. This will allow the gateway to start and serve other functionality even if a plugin's config is invalid.