Too many messages processed/returned by API?

[elavy-harris]

I’ve got a program that purges messages from Mirth using the “DELETE /channels/{channelId}/messages” API. I hadn’t realized at first that the startDate/endDate apply to the original received date, not to the one I see on the message list.

In an attempt to test my new understanding, I reprocessed an old message, checking the “Overwrite existing statistics and update statistics” checkbox, then did a delete using a time range that encompasses the original received date.

The message went away, but so did 4 others that I didn’t expect to be deleted.

I’m trying to cobble together data about the pre-delete state of the system and what I did, but there are holes.

Screenshot showing messages 1-7. Message 1 is the one I reprocessed. Times are -06:00 for January and -05:00 for June.

Contents of table d_m13, for messages 1-8:

Parameters passed to DELETE, as a python dict (I expected this to delete messages 1-4):
{'channelId': 'd04e8e83-93d1-4559-83d6-50216613cb24', 'startDate': '2023-01-01T00:00:00.000000+0000', 'endDate': '2023-01-10T22:38:59.999000+0000'}

FULL contents of d_m13, after the delete:

Any idea why messages 5-8 went away?

Thanks in advance.

[elavy-harris]

I was able to find a backup of the database and have been doing some testing on that. I get too many messages on a GET, also.

I've found that the number of digits in endTime makes a difference. With an endDate of 2023-01-10T22:38:59.999000+0000, I get 8 messages. With an endDate of 2023-01-10T22:38:59.999+0000, I only get 4. (The difference is .999000 vs. .999.)

Seems like a bug. Yes?

[elavy-harris]

Here's an example of a curl command that returns too many messages:

curl -ksu elavy -X GET "https://localhost:18443/api/channels/d04e8e83-93d1-4559-83d6-50216613cb24/messages?startDate=2023-01-01T00%3A00%3A00.000000%2B0000&endDate=2023-01-10T22%3A27%3A59.999000%2B0000&limit=20" -H "accept: application/xml" -H "X-Requested-With: OpenAPI"

[elavy-harris]

I don't know where the code is, but I think I know what's going on.

After getting an ordinal time from whole seconds, Mirth seems to be taking the number after the decimal point, dividing by 1000, and adding to the ordinal. "2020-01-01T00:00:00.001234", then, is interpreted as "2020-01-01T00:00:01.234".

[pacmano1]

If you have repeatable results here - I would go open a bug report in the "Issues" section.

[elavy-harris]

Opened #6230