Skip to content
This repository was archived by the owner on May 27, 2025. It is now read-only.

presenceSub needs to re-run on reconnections #576

@kippr

Description

@kippr

The slack rtm client handles reconnections automatically, but when it does so, subscriptions for presence_change events are lost. This means after one or more autoReconnects, presenceChange events will not fire.

Fix: I've taken a stab at fixing this in a fork and confirmed it works as expected. I'm not a javascript/ coffeescript programmer tho, so I had a scoping issue with @presenceSub in bot.coffee that I got around by inlining.. kippr@c35a109

What type of issue is this? (place an x in one of the [ ])

  • bug
  • enhancement (feature request)
  • question
  • documentation related
  • testing related
  • discussion

Requirements (place an x in each of the [ ])

  • I've read and understood the Contributing guidelines and have done my best effort to follow them.
  • I've read and agree to the Code of Conduct.
  • I've searched for any related issues and avoided creating a duplicate issue.

Bug Report

Reproducible in:

hubot-slack version: 4.7.1

node version:

OS version(s):

Steps to reproduce:

The simplest way to see this is to watch the debug logs, but you can also create a simple hubot script that does something on presence changes. (robot.presenceChange (msg) callback)

  1. Connect hubot to your slack instance
  2. Start the slack client
  3. monitor for 'Received presence change update message [..]' in debug logs for your connection/ disconnection events by starting/ quitting client
  4. use tcpkill or some other tool to disrupt hubot's connection to slack; hubot will reconnect
  5. monitor for same presence change messages

Expected result:

The messages should keep firing.

Actual result:

They don't because the subscriptions for presence change events don't get created on the new connection.

Attachments:

Logs, screenshots, screencast, sample project, funny gif, etc.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugM-T: A confirmed bug report. Issues are confirmed when the reproduction steps are documented

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions