zulip: API usage problem with message IDs (invalid message / BAD_REQUEST)

• Zulip version: 2.1.0-5-g49ff894d6a
• OS version: Ubuntu 18.04.3 LTS (bionic)

We currently have some seemingly strange problems by using Zulip API with message IDs (e.g. with message deletion).

Initially we created a new (generic) bot in Zulip and enabled message deletion as described (https://zulipchat.com/help/configure-message-editing-and-deletion). On this way we are able to successfully send messages (which also then are shown up correctly in Zulip web/desktop/mobile client):

curl -X POST https://zulip.domain.com/api/v1/messages \
    -u alert-bot@zulip.domain.com:APIKEY \
    -d "type=stream" \
    -d "to=Alert" \
    -d "subject=Test" \
    -d $"content=TEST - Event ID #5000"

{"result":"success","msg":"","id":78539}

But strangely it is not possible to get the message or to delete it via API by using the (correct) message ID:

curl -sSX GET -G https://zulip.domain.com/api/v1/messages/78539 \
    -u alert-bot@zulip.domain.com:APIKEY

{"result":"error","msg":"Invalid message(s)","code":"BAD_REQUEST"}

curl -sSX DELETE https://zulip.domain.com/api/v1/messages/78539 \
    -u alert-bot@zulip.domain.com:APIKEY

{"result":"error","msg":"Invalid message(s)","code":"BAD_REQUEST"}

We get then a BAD_REQUEST (400) error - which seem to related to a user indicated “invalid/unknown” message id (https://zulipchat.com/api/rest-error-handling).

So it seems that the message ID does not exist - but it is possible to query for the correct message (with narrow: https://zulipchat.com/api/construct-narrow) and this shows that the message ID actually exists indeed:

curl -sSX GET -G https://zulip.domain.com/api/v1/messages \
    -u alert-bot@zulip.domain.com:APIKEY \
    -d 'use_first_unread_anchor=true' \
    -d 'num_before=1000' \
    -d 'num_after=1000' \
    --data-urlencode narrow='[{"operator": "stream", "operand": "Alert"}, {"operator": "sender", "operand": "alert-bot@zulip.domain.com", "negated": false}, {"operator": "search", "operand": "#5000"}]'

{"result":"success","msg":"","messages":[{"id":78539,"sender_id":49,"content":"<p>TEST - Event ID #5000<\/p>","recipient_id":152,"timestamp":1578002626,"client":"curl","subject":"Test","subject_links":[],"is_me_message":false,"reactions":[],"submessages":[],"flags":["read","historical"],"match_content":"<p>TEST - Event ID #<span class=\"highlight\">5000<\/span><\/p>","match_subject":"Test","sender_full_name":"Alert","sender_short_name":"alert-bot","sender_email":"alert-bot@zulip.domain.com","sender_realm_str":"","display_recipient":"Test","type":"stream","stream_id":105,"avatar_url":"https:\/\/secure.gravatar.com\/avatar\/0ebefs3b5d3581f24cf8d3fad67ac760?d=identicon&version=1","content_type":"text\/html"}],"found_anchor":false,"found_oldest":true,"found_newest":true,"history_limited":false,"anchor":10000000000000000}

In the Zulip logs we didn’t found any helpful information in this context. For us it is currently not understandable where exactly the problem source lies - and we would be grateful for every hint…