The RLOG DB backend tests in FVT were temporarily disabled due to some
paho tests being specially flaky in CI.
In particular, those tests had the common pattern of subscribing to a
topic, immediately publishing to that topic and then waiting for the
response. When in CI and using RLOG, there seems to be more delays in
replication of data, and often this pattern would fail in the
constraint testing enviroment.
* fix(dashboard_api): delete non-exist user wrongly return 204
* fix(dashboard): dashboard user should use `tags` not `tag`
* fix(dashboard): create/update user return 200 with full users list
* fix(dashboard): logout status code 204
* fix(dashboard): update pwd status code 204
* test: test suite for dashboard APIs
* refactor(dashboard): user info mnesia record name use description
* style: make elvis happy
* fix(api): dashboard swagger check request should not override env
* fix(dashboard): add/modify dashboard returns single record
* ci: update emqx-fvt version to new tag 1.0.2-dev1
* test(persistent_session_SUITE): remove redundant sleep and trap_exits
* test(persistent_session_SUITE): fix race for started snabbkaffe
Sometimes snabbkaffe was not started when publishing from a different
process. Wrap the publishing code in a ?check_trace to make sure it is
started, and make sure the publish process is truly down before ending
the trace.
* test(persistent_session_SUITE): fix takeover race
Make sure the previous session is unregistered before trying to
connect again. Sometimes the new session was trying to take over the
session that was shutting down still.
ordered_set is compatible to set in all the existing APIs
and in addition, it provides a more deterministic traversing
cursor in case we want to change the current dirty_select
based "select ALL" implementation
Prior to this fix, 'kick' and 'discard' calls may timeout (or
fail for other reason), failures lead to only a log, then
continue to allow the new session to get registered.
As a result, in case a client is stuck, there is no way to
force it to step down, end up with multiple connections (sessions)
for the client ID in dashboard.
After this fix, the stale pids are notified to shutdown
via a gen_server:call, and forced with a exit(Pid, kill) for any
exception happend to the gen_server:call
Thales Macedo Garitezi