The workaround proposed by @martini also worked for us. Using Channel.find_by(area: 'Twitter::Account') to find the channel id from the console as suggested by @MrGeneration also worked.
I’ve noticed on all the zammad deployments I’ve managed where this occurs, the id in the database and the real id always differ by the last two digits.
Example:
- real id: 984608854112718848
- erroneous id saved by zammad: 984608854112718800
This also only happened on accounts where the id is very long number, not on accounts with shorter ids.
Could this be some sort of precision bug? Zammad is storing the id as a long/integer type. But it should probably be a string for safety.
More research:
Yes, I’m convinced this is the root of the problem. All the broken id’s I’ve seen are greater than Number.MAX_SAFE_INTEGER in javascript.
I believe that when the twitter channel is added in zammad, the channel’s roundtrip through the ui is breaking the value of the id.
Even Twitter themselves warn about this:
Tweet IDs can break Javascript
Use the id_str field instead of id whenever present to stay safe. Web browsers/Javascript interpreters/JSON consumers may munge large integer-based ids, which is why it is recommended to use the string representation.