messageToJson is called for ID 9 sometimes

[link2xt]

DC desktop throws this warning when rendering any chat for me:

12.9s [D]core/event: DC_EVENT_WARNING  dc_get_msg called with special msg_id=9, returning empty msg
12.9s [D]main/deltachat: sendToRenderer: DC_EVENT_WARNING
12.9s [w]main/deltachat: dc_get_msg called with special msg_id=9, returning empty msg

That happens because DCMessageList._messagesToRender is called with a list that contains ID 9. These IDs come from this._dc.getChatMessages, which calls get_chat_msgs via node bindings.

For some reason, my database contains special IDs in msgs table:

$ sqlite3 ~/.config/DeltaChat/*/db.sqlite 'select * from msgs where id<=9'
1|||0|0|0|0|0|0|0|0|0||||0|0|0|0||||1|0
2|||0|0|0|0|0|0|0|0|0||||0|0|0|0||||1|0
3|||0|0|0|0|0|0|0|0|0||||0|0|0|0||||1|0
4|||0|0|0|0|0|0|0|0|0||||0|0|0|0||||1|0
5|||0|0|0|0|0|0|0|0|0||||0|0|0|0||||1|0
6|||0|0|0|0|0|0|0|0|0||||0|0|0|0||||1|0
7|||0|0|0|0|0|0|0|0|0||||0|0|0|0||||1|0
8|||0|0|0|0|0|0|0|0|0||||0|0|0|0||||1|0
9|||0|0|0|0|0|0|0|0|0||||0|0|0|0||||1|0

I don't know if that is because of the bug in some previous version of DC because I restore from backup, but still, my backup and backups/databases of others may contain these IDs.

Not sure how to solve this. The simplest solution seems to be to filter out these IDs in SQL queries. Maybe we can delete them from the database?

[link2xt]

Reports on whether your databases contain these IDs are also interesting. Is everyone affected by this bug?

[r10s]

ID 9 is DC_MSG_ID_DAYMARKER. this is a special message id that is inserted to a chat-list on new day starts. if the ui uses a virtual list, it can easily add day-headlines.

calling dc_get_msg(), however, for DC_MSG_ID_DAYMARKER does not make much sense.

For some reason, my database contains special IDs in msgs table

this is by design. on database creation, for the special-ids, the corresponding records are created, mainly to avoid accidentally creation of the record, but also to store data as needed.

[flub]

There was a recent PR from @hpk42 which in which he re-added the behaviour to return an empty message if requested with a special message id, he probably added the warning at that time (desktop really shouldn't be calling this with an invalid id but it does).

Before that desktop got errors back from that call instead and didn't cope well with it. This all started somehow with my msgid refactor which attempted to make this a bit more strict.

[flub]

oh wait, i'm really late to this party. ignore me. i may go back to being more strict in the core now though ;)