Hi,Jan, Thanks for the advice, I totally agree with you. It's much better to report an error loudly than silently.
For the first one, we did a test[1] but there is no error and no stop-start, it's an error, feel free to submit a PR to fix it. For the second, the plugin's init function does not actually run in nginx's init_by_lua block, But we can also consider other ways to handle. [1] https://github.com/apache/incubator-apisix/blob/master/bin/apisix#L801 Thanks, Ming Wen, Apache APISIX & Apache SkyWalking Twitter: _WenMing Jan Li <jan...@airwallex.com> 于2020年5月8日周五 下午7:44写道： > Hi team, > > When using APISIX in critical env, we'd like it fail fast to avoid > false healthy server which cannot process any actual requests: > > 1. If APISIX cannot connect to ETCD when it's configured with the > ETCD config center, it means pre-configured routes are not available. At > this point, APISIX should fail the start, but currently it starts as if > everything is fine, but since all preconfigured routes are not available, > it cannot serve any real business requests. > 2. If a plugin has a critical init phase which should be completed > before the plugin can be used in request processing, and the init phase > throws an error. APISIX should fail at the start in such cases, since it > cannot process any real business requests which have that fail-to-init > plugin configured. > > For the first, I think APISIX should verify ETCD connectivity if > configured to use ETCD as the config center. > > For the second, I think every plugin should be able to declare some > critical method which must be completed before the plugin is ready to serve > requests, such as a main_init() method which will be called inside > init_by_lua_block phase. If such a plugin fails to init itself, APISIX > should not start itself. >
