Gujiawei-Edinburgh commented on issue #236: URL: https://github.com/apache/bifromq/issues/236#issuecomment-4122623707
> During our initial production deployments, we encountered multiple incidents where critical functionality failed simply because the following plugin fields were not explicitly configured in `standalone.yml`: > > * `authProviderFQN` > * `resourceThrottlerFQN` > * `settingProviderFQN` > > Currently, if these fields are not explicitly declared, the system will not use any corresponding plugin at all, but instead either skip the functionality entirely or fall back to an inappropriate default behavior (e.g., using a development-only auth provider). This can easily introduce security or performance risks in production environments and significantly increases the cost of troubleshooting. > > **Proposed Improvement:** > > 1. **When a plugin field (e.g., `authProviderFQN`) is _not configured_ in `standalone.yml`:** > > * Automatically discover all registered custom plugin implementations. > * Sort them by their plugin key in byte-wise alphabetical order and select the first one as the default. > * If no custom plugins exist, fall back to the current built-in default (e.g., the development-only auth provider). > 2. **When a plugin is explicitly configured but fails to load** (e.g., due to class not found or initialization error): > > * Do **not** crash the startup process. Instead, gracefully degrade by applying the same auto-selection logic described above. > 3. Apply this behavior consistently across all three fields: > `authProviderFQN`, `resourceThrottlerFQN`, and `settingProviderFQN`. > > This enhancement would greatly improve deployment reliability—especially for new or clustered production environments—while maintaining backward compatibility. Given our real-world experience with configuration oversights, we believe this change would benefit many users. > > Thank you for considering this suggestion! I think it is common in plugin development since we move part of the ownership to the users. And falling back to dev-only plugin is more intuitive from my perspective, because the user may be more familiar with the dev-only behavior which can be more predictable and detectable. And we have to document the behavior changes as well. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
