This applies to both the DM to be sent to the user, and the message
created in the thread channel.
This is because edits (via !edit) could change the amount of messages
a reply takes (based on message formatting), leading to either being
unable to post the full edit if it goes over the message limits, or
having to edit a previous message to be 'empty' if the result of the
edit would take fewer messages to post than the original reply.
This also fixes an issue where !edit/!delete would not apply to more
than the first message created by a reply - whether in user DMs or in
the thread channel.
The logic could cause things like code blocks get cut in the middle
without being handled gracefully. With this change, messages sent
to the user can take, at most, 1 message. This does not affect
messages in the thread channel.
Internally, the thread_messages table's body column's type was
undefined in sqlite. This is because it was set to mediumtext, but
sqlite doesn't have that type. Because of that, sqlite treated the
column as a numeric column. Sqlite also allows storing text data in
numeric columns (because reasons), so in most cases everything worked
fine. It was only when storing an actual number, like an ID, that it
was also *treated* as a number. And since snowflake IDs are larger
than the maximum safe integer in JavaScript, the stored ID could get
rounded when retrieving data from the database.
This has backwards-compatibility-breaking changes to the formatters
of staff reply edits/deletions, which now only receive the
thread message for the edit/deletion with the original data in
the thread message's metadata.
This is to allow other features to use the /logs folder.
Going forward, updating from a pre-Feb 2018 version of the bot
will require first updating the bot to version v2.30.1 and running it
once. After that, updating to newer versions is possible.
Dragory
Nils