[This issue was migrated from GitLab and was originally posted on 2018-12-10.]

The production instance of the bot will sporadically lose connection to Discord a few times a day, logging the following message:

4-12-2018 15:55:52 : [Warning] Gateway :
System.Exception: WebSocket connection was closed ---> System.Exception: Unexpected close
   --- Einde van intern uitzonderingsstackpad ---
   bij System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   bij System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   bij Discord.ConnectionManager.<>c__DisplayClass28_0.<<StartAsync>b__0>d.MoveNext()
4-12-2018 15:55:52 : [Info] Gateway : Disconnecting
4-12-2018 15:55:52 : [Info] Gateway : Disconnected
4-12-2018 15:55:53 : [Info] Gateway : Connecting
4-12-2018 15:55:54 : [Info] Gateway : Resumed previous session
4-12-2018 15:55:54 : [Info] Gateway : Connected

This happens randomly and the bot has successfully re-established connection every time until december 7th, when it failed to reconnect and this was not noticed until december 10th.

7-12-2018 20:13:01 : [Warning] Gateway : Unknown Dispatch (PRESENCES_REPLACE)
7-12-2018 20:35:22 : [Warning] Gateway : Failed to resume previous session
7-12-2018 20:35:22 : [Info] Gateway : Disconnecting
7-12-2018 20:35:22 : [Info] Gateway : Disconnected
10-12-2018 11:06:33 : [Info] Main : Ctrl-Q pressed
10-12-2018 11:06:34 : [Info] Main : Stopping bot

I don't know if the "unknown dispatch" message is related to the problem, but I have seen this warning sporadically since the first time I touched Discord.NET. I have no idea why it happens.

Users are tempted to include the identifier of their last query when using !daarna, despite the fact that it remembers what that was. I've not had any real feedback on this but I can assume this is annoying.

Suggested fix: give !daarna a parameter [Remainder] string ignored = "" and give the user a hint when the parameter is not empty.

At 12:54 pm I used: !ov hilversum to find alternatives for the delayed train I was waiting for, which had been delayed 5 minutes after its scheduled departure time at 12:57.

This train showed up second in the list, before it was a train which had already departed at 12:34.

This might be a clock issue, an issue with the NS API, or I might need to tell the API not to show journeys that have already passed. The NS Reisplanner app, which uses the same API, also shows one journey which has already passed, but I have not noticed this issue before, so I assumed it was a parameter that I did not set.

And display the count down to seconds.

It should find the nearest train station instead, and also warn that it cannot look up bus routes.

To do this we might need to add all towns into the list of stations, and a flag indicating if the town has a station. We also need to add the coordinate location for each item, existing and new. All of this was already present in the stations.xml file as downloaded from the NS dev page, which was stripped down when we started using it. We can download it again without stripping it down.

When the station search returns a location with no station, it should search the list again, looking for the nearest train station to the requested location. This could take a few seconds per request, so we should add a rate-limit to this feature.