This reworks a test case to use a second slave node. This ensures that
an added route is permanently in the routing table. The old version
reverted the routing table quickly since the node name given wasn't a
real node.
We only deleted the resulting zip after a trace file download, not the
actual trace files. This adds a deletion of the uncompressed trace files
as well. It also creates unique directories when collecting trace files
so that concurrent downloads doesn't overwrite files in transit.
This flag indicates whether there are more results available on the
next pages. It is needed in cases when the total number of search
results is not known in advance.
Also, in such cases there's no `count` field in responses anymore
because responding with `0` was confusing for clients: it's not possible
to differentiate between "there are no results" and "we don't know how
much".
Co-authored-by: Thales Macedo Garitezi <thalesmg@gmail.com>
Testcase `t_log_file` was flapping when run happened to pass through
boundary of a second. Archive files' `ctime`s could differ between
consecutive archive downloads.
Add test coverage for HTTP 204 returns from lwm2m client API
posts. This includes a small refactoring of the request functionality
in emqx_mgmt_api_test_util.
Prior to this change, the publish API returns 200 in most of
the cases.
This change provides more insights to the publish result.
For single message publish endpoint (`publish/`):
HTTP error codes are:
200: Everything is OK
202: No subscriber for the topic
400: When mesage is invalid message.
e.g. bad topic name or QoS out of range.
503: Failed to dispatch the message. e.g. during EMQX restart.
The response body is a JSON object with two fields
`message_id`, and `publish_result`.
The `message_id` is a globally unique ID for tracing.
`publish_result` is `"OK"` when the message is delivered
to at least one subscriber.
Otherwise `"no_subscriber"`.
`publish_result` may also be some other informative
message to hint the failure result, the content of which
may change in the future.
For `publish/bulk` endpoint:
200: When all message in the bulk are published OK
202: If at least one message in the bulk had `"no_subscriber"` result
400: When mesage is invalid message. e.g. bad topic name or
QoS out of range.
503: When there is at least one message failed at dispatch.
The reply body is a list of JSON objects having the same layout
as for hte `publish` endpoint.
