bot.Listing Randomly locking up.

[chand1012]

I run a Discord bot using graw to get content from Reddit. To minimize API calls to Reddit, 100 posts from the most popular subreddits are cached on the server running the bot, also gotten with graw. After an hour the posts expire and graw retrieves 100 more posts per subreddit. I am having an issue that after one or two refreshes of the post cache, bot.Listing completely locks up the bot. Sometimes, it isn't after an hour or two, its as soon as I start the bot and it attempts to populate the post cache, to which nothing happens as bot.Listing has locked up. This just started happening a few days ago, and I was immediately notified of the issue by my users who apparently use the bot as their method of Reddit content consumption. This issue happens whenever the bot calls graw, either when populating the cache, or when a user requests content from a subreddit that is not usually cached.

The API keys are valid, I just regenerated them a few days ago. It doesn't seem to be a memory issue, memory use doesn't build over time nor does any sort of error appear. I have proper error handling, but because bot.Listing is hanging, no error returns at all. Restarting the bot a few times fixes the issue, but this is not a permanent fix, especially since occasionally restarting doesn't fix the issue. The bot is currently built using a Go 1.13 Docker container, which will soon be updated to 1.15. In testing the problem, I tried using both 1.13 and 1.15 but neither made a difference.

Does anyone have any insight on what could possibly be causing the issue?

[chand1012]

In attempting to fix the issue, I reverted graw back to an older version that the bot used to run on, that being 2481430. This changed fixed the issue, so something changed between the current release and that previous commit made bot.Listing unreliable for my case. Does anyone know what could have caused this and why it's not spitting back out an error?

[turnage]

bot.Listing calls this function.

From a quick glance my only suspicion about that function is changes to parsing in #79.

To anyone who can reproduce this issue, it would be fantastic to know:

1. What a debugger claims the stuck goroutine is doing.
2. Whether reverting 8ef4107 fixes the issue for you.