Open imzs opened 1 week ago
Returning an additional handle in all send Response operations introduces overhead. If this feature is not required, there should be an option to disable it.
Returning an additional handle in all send Response operations introduces overhead. If this feature is not required, there should be an option to disable it.
This field is somewhat similar to transactionId
. As previously mentioned, the API defines a common semantic. In cases where unsupported message types are encountered, it returns null values, which also implies that the current message does not support recall operation, this may be considered as a switch.
It seems that the newly added integration test are failing.
It seems that the newly added integration test are failing.
The tests passed locally, it maybe timeout issue; I'll try to fix it.
Attention: Patch coverage is 65.77540%
with 128 lines
in your changes missing coverage. Please review.
Project coverage is 48.06%. Comparing base (
715dd5a
) to head (b50755f
). Report is 7 commits behind head on develop.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
[ISSUE #8974] Support recalling of delay message