Skip to content

Make the bot not crash when a channel mentioned by ID fails to exist #201

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 29, 2017

Conversation

Throne3d
Copy link
Collaborator

@Throne3d Throne3d commented Mar 24, 2017

Description

If a channel is referenced in Discord, e.g. <#1234>, and the referenced channel does not exist, the bot seems to crash. This commit fixes it to replace this with '#deleted-channel', as Discord does on that side of the bridge.

Present behavior

Writing #blah, <#test> and <#1234> into IRC causes the bot to show (in Discord):

<Throne> #blah
<Throne> <#test>
<Throne> #deleted-channel

and then writing the same into the Discord channel causes (in IRC):

[22:13:39] <test2> <Throne3d> #blah
[22:13:41] <test2> <Throne3d> <#test>
[22:13:44] * test2 has quit (Client exited)

The crash produced:

/home/throne3d/discord-irc/dist/bot.js:159
      return `#${channel.name}`;
                        ^

TypeError: Cannot read property 'name' of undefined
    at text.replace.replace (/home/throne3d/discord-irc/dist/bot.js:159:25)
    at RegExp.[Symbol.replace] (native)
    at String.replace (native)
    at Bot.parseText (/home/throne3d/discord-irc/dist/bot.js:157:45)
    at Bot.sendToIRC (/home/throne3d/discord-irc/dist/bot.js:179:23)
    at Client.discord.on.message (/home/throne3d/discord-irc/dist/bot.js:113:12)
    at emitOne (events.js:96:13)
    at Client.emit (events.js:191:7)
    at MessageCreateHandler.handle (/home/throne3d/discord-irc/node_modules/discord.js/src/client/websocket/packets/handlers/MessageCreate.js:9:34)
    at WebSocketPacketManager.handle (/home/throne3d/discord-irc/node_modules/discord.js/src/client/websocket/packets/WebSocketPacketManager.js:120:65)

The new test (and stubbing behavior) I add with this patch fails on master as follows:

  1) Bot should use #deleted-channel when referenced channel fails to exist:
     TypeError: Cannot read property 'name' of null
      at text.replace.replace (lib/bot.js:7:2326)
      at RegExp.[Symbol.replace] (native)
      at String.replace (native)
      at Bot.parseText (lib/bot.js:7:2147)
      at Bot.sendToIRC (lib/bot.js:8:652)
      at Context.<anonymous> (test/bot.test.js:271:14)

Modified behavior

With the change, it only returns the channel's name where the channel is truthy. (I'm not very acquainted with modern techniques so this might not be the best way to do it? It seems to be undefined as returned by this.discord.channels.get(channelId) but null as returned by the stub, so checking channel === undefined didn't catch that.)

Otherwise, it returns #deleted-channel (and so writes that into the IRC channel), mirroring the behavior seen in Discord for such invalid channel IDs. This doesn't break any other tests (at least not on my system). The && value == undefined condition is to check for when a second parameter isn't given – I wasn't sure whether to use && !value or something else instead.

If a channel is referenced in Discord, e.g. <#1234>, and the
referenced channel ID does not exist, the bot will presently
crash. This fixes it to display '#deleted-channel', as it
does on the Discord side of the mirror.
@coveralls
Copy link

Coverage Status

Coverage increased (+0.02%) to 97.368% when pulling f882e15 on Throne3d:fix/crash-on-undefined-channel into 26626e5 on reactiflux:master.

@ekmartin
Copy link
Member

Great, thank you!

@ekmartin ekmartin merged commit 25eae44 into reactiflux:master Mar 29, 2017
@Throne3d Throne3d deleted the fix/crash-on-undefined-channel branch March 29, 2017 20:25
@ekmartin
Copy link
Member

ekmartin commented Apr 4, 2017

Released in 2.3.0!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants