Don't receive Twitter DMs / railsserver error

We’re still not able to reproduce this, I currently wait for feedback of Lapotor as he might gimme a clue to be able to reproduce this.

If you want to, you can try reproducing this on a hosted instance:

As per my comment in this other thread I have the same problem…

I’m wondering if this might be due to the fact that I changed the twitter username? I tested changing the username of the twitter account but it made no difference…

I’m running 2.8

I want to try this as a possible fix but how do I know that Channel.find(12) is the same channel for me? I my production.log file I only see execute Channel.fetch (try_count 0)...

Can I just change c = Channel.find(12) to c = Channel.fetch and run the commands above?

Can I add the same twitter app details in order to test this on a hosted instance?

I think the error occurs when the account that registers the app is different than the one that registered the channel.

Had the same idea. I checked it and it still don’t work.

I can definitely tell that this is not the case for me.
I’ve got a dev account at Twitter and my “Verein” doesn’t - the “Verein” does use the app I provide.

@bruce78 I’ll work something out for you to test, please provide a Zammad-URL via DM so I can enter it.

1 Like

Any Feedback, @bruce78 ? :slight_smile:

@MrGeneration Hi Marcel

I’ll work something out for you to test, please provide a Zammad-URL via DM so I can enter it.

I didn’t get anything to test? Nothing in Zammad and nothing on Twitter, did you get my private message on this site?

@MrGeneration OK, see my PM for some testing results…

1 Like

Just a small follow up for any one watching this: We’re at it, a developer is taking a look.


When I need to guess I would say there is no news yet?

I’m afraid that you’re right :frowning:

Ok, the work-around below worked for me with a couple of caveats…

  1. You need to find the channel ID from your browser when adding the twitter account, it just loads a url with the channel number at the end e.g. or similar. I don’t know if there is another way to find the twitter channel ID?
  2. The user ID comes from the error message in the log e.g.
E, [2019-02-20T09:56:26.187680 #5546-46915235956760] ERROR -- : No such channel for user id '123456789123456'! (Exce
/opt/zammad/app/controllers/channels_twitter_controller.rb:32:in `validate_webhook_signature!'

These are the commands I ran on the server…

Does anyone know if this fix is upgrade safe?

Hey @bruce78, thanks for your efford!

Normally you would find that information via rails console with:
Channel.find_by(area: 'Twitter::Account')

But in your case it looks like the ID is invalid so hard to tell to be honest.

The solution martin provided is a permanent solution, this will be stored in your database and thus is update safe.

1 Like

Yeah, I just made up the actual twitter ID for the public post but I found the real one in the logs without any problems…

It’s good to know that this work-around is upgrade safe!

1 Like

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.


  • 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.


Thanks for your feedback!
We’ll discuss this, this will proberbly a bug (or atleast an enhancement).

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.

Hey @abelxluck I just wanted to let you know that this issue got some traction today and your investigation helped us to get on the right track (pretty fast). Thanks a lot! Fix is on the way!