* The code for passing the trace context to a sub process has been
improved to increase code reuse. This code is used when the action
templates are rendered in a sub process.
* A macro has also been added for the error term that is thrown when the
action shall be stopped after the templates has been rendered. This is
also done to reduce code duplication and to reduce the risk of
introducing bugs due to typos.
* Fix incorrect type spec
Thanks to @zmstone for suggesting these improvements in comments to a PR
(https://github.com/emqx/emqx/pull/12916).
This commit:
* refactors the MQTT V1 bridge into connector, source and action
* Extends the compatibility layer so it works for sources
* Fixes the MQTT bridge test suite so that all test cases passes
We still need to add a HTTP API handling sources. Also, we still need to
add HTTP API example schemes and examples for the MQTT
connector/action/source.
We should also make sure that we handle the corner cases of the MQTT V1
bridge automatic upgrade downgrade in a sufficiently good way:
* An error is currently thrown when converting an MQTT V1 bridge without
egress or ingress config.
* If there is a source and action with the same name we will currently
throw an error in the compatibility layer.
* We will also throw an error when converting an MQTT V1 bridge with
both ingress and egress.
The above is probably the right thing to do but we have to make sure
that we return a reasonable error to the user when this happens.
(partly)
Fixes:
https://emqx.atlassian.net/browse/EMQX-11489
Some mqtt brokers do not allow long client IDs.
To make it compatible with this limitation, this commit
tries to limit the number of bytes under 23 with a best-effort
attempt to derive it from the bridge name.
Co-authored-by: Thales Macedo Garitezi <thalesmg@gmail.com>
Co-authored-by: Stefan Strigler <stefan.strigler@emqx.io>
Co-authored-by: Zaiming (Stone) Shi <zmstone@gmail.com>
Several bridges should be able to share a connector pool defined by a
single connector. The connectors should be possible to enable and
disable similar to how one can disable and enable bridges. There should
also be an API for checking the status of a connector and for
add/edit/delete connectors similar to the current bridge API.
Issues:
https://emqx.atlassian.net/browse/EMQX-10805
They are intended to be used mostly in the context of resources, which
have their own feedback mechanism: statuses, retries, etc.
Also turn the error into a throw exception, so that it can be
interpreted as a regular error condition, for example by the resource
manager.
We need to reverse the dependency of `emqx_bridge` and `emqx_bridge_*`, because the former
loads and starts bridges during its application startup. If the individual bridge
application being loaded has not started with its dependencies, the supervision tree will
not be ready for that.
Kjell Winblad