Skip to content
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

Bot will not restart if network connectivity is lost #35

Closed
danirod opened this issue Nov 16, 2019 · 2 comments
Closed

Bot will not restart if network connectivity is lost #35

danirod opened this issue Nov 16, 2019 · 2 comments
Assignees
Labels
bug Something is not working tracking issue This describes an existing or future pull request
Milestone

Comments

@danirod
Copy link
Member

danirod commented Nov 16, 2019

The bot sometimes disconnects from the network but doesn't attempt to reconnect when the network is available again.

@danirod danirod added bug Something is not working tracking issue This describes an existing or future pull request labels Nov 16, 2019
@danirod danirod added this to the Clank 1.0 milestone Nov 16, 2019
@danirod danirod self-assigned this Nov 16, 2019
@danirod danirod added this to To do in Infrastructure Kanban via automation Nov 16, 2019
@danirod danirod added this to Needs triage in Triaging via automation Nov 16, 2019
@danirod
Copy link
Member Author

danirod commented May 3, 2020

Merged in #110 something that may fix this. Need to keep this opened in case it doesn't fix it.

@danirod danirod added the blocked Cannnot be dealed with at the moment label May 17, 2020
@danirod danirod pinned this issue Jun 25, 2020
@danirod danirod removed the blocked Cannnot be dealed with at the moment label Jul 1, 2020
@danirod
Copy link
Member Author

danirod commented Jul 1, 2020

#151 seems to fix this issue. The following snippet was added to the docker-compose that manages the main instance running in production:

healthcheck:
  test: wget -qO- http://localhost:8080/healthcheck
  interval: 30s
  timeout: 10s
  retries: 3

Recently some correlations between users whose !accept request was ignored by the bot and the restart schedule for the bot have confirmed unless the contrary is said, that whenever the bot loses connectivity, its status changes from READY to something else, although it hasn't been confirmed because of the lack of logging events made by the bot.

This issue will be closed and marked as fixed unless we see it happening again.

@danirod danirod closed this as completed Jul 1, 2020
Infrastructure Kanban automation moved this from To do to Done Jul 1, 2020
Triaging automation moved this from Needs triage to Closed Jul 1, 2020
@danirod danirod unpinned this issue Jul 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working tracking issue This describes an existing or future pull request
Projects
No open projects
Development

No branches or pull requests

1 participant