Smokedetector: Smokey Stops reporting the first feedback for posts
I've seen this happen a few times. After a period of not being rebooted, smokey stops adding chat messages in CharcoalHQ like this:
Instead, not message appears even though people _have_ provided feedback for the post.
Rebooting smokey seems to fix the problem. I think someone mentioned a websocket timing out when we have discuss this in the past but I can't be sure.
SulphurDioxide
All 9 comments
This is why I think we should switch to a proper ActionCable client implementation.
j-f1
on 14 Jul 2017
Has this happened again recently?
quartata
on 27 Nov 2017
I'll keep an eye out for the next few days. It definitely happened within 2 weeks.
SulphurDioxide
on 27 Nov 2017
Has this been reproduced recently?
angussidney
on 26 Apr 2018
Nope. I haven't seen this recently.
SulphurDioxide
on 26 Apr 2018
This has started happening again. See the transcript here: https://chat.stackexchange.com/transcript/message/45606961#45606961
and the conversation afterwards.
SulphurDioxide
on 12 Jul 2018
This issue has been closed because it has had no recent activity. If this is still important, please add another comment and find someone with write permissions to reopen the issue. Thank you for your contributions.
![stale[bot] picture](https://avatars3.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 30 Oct 2019
This has been happening fairly often lately, though I don't know for sure if it has increased in frequency. It doesn't seem to depend on which instance of Smokey is being used. Smokey isn't losing its ability to post messages in the room--it still reports posts and replies to commands.
@double-beep has observed that it seems to be triggered by a large number of commands issued in a short time.
EliahKagan
on 27 Feb 2020
We're going to need to watch to see if this is actually resolved. However, I fixed an issue which would have caused the problem.
The issue I fixed was that after the WebSocket to MS is initially established, if an exception occurred (e.g. an error or the WebSocket was closed by MS), then SD would attempt to re-establish the connection, but would not transmit it's security key, which would cause the attempt to reestablish the WebSocket to fail in a way that caused SD to think that things were OK. Thus, once disconnected, the WebSocket connection would never be actually reestablished.
makyen
on 29 Feb 2020
Related issues
tripleee
路
4Comments
angussidney
路
9Comments
angussidney
路
8Comments
Tyler-H
路
3Comments
tripleee
路
7Comments
Most helpful comment
We're going to need to watch to see if this is actually resolved. However, I fixed an issue which would have caused the problem.
The issue I fixed was that after the WebSocket to MS is initially established, if an exception occurred (e.g. an error or the WebSocket was closed by MS), then SD would attempt to re-establish the connection, but would not transmit it's security
key, which would cause the attempt to reestablish the WebSocket to fail in a way that caused SD to think that things were OK. Thus, once disconnected, the WebSocket connection would never be actually reestablished.