Prevent tag commands while tag data is refreshing

[gunr2171]

I don't even want to know what will happen if you try to run a "get tag data" command while the tags are being refreshed. But it's probably not a good thing.

The bot should either wait for the command to finish or reject the request, depending on what is being called.

If you do multiple refreshes:

Another tag refresh is already going. Please wait for it to finish. For more information use the command running commands.

If you try to access the tag list:

A tag refresh is in progress. I'll get your data as soon as it's done.

[Unihedro]

Why not schedule the request to be repeated afterwards, much like a queue-based event executor? Of course, it should also be sane enough to reject frequent requests, i.e. for specific types we define, ignore requests that are done within X moments of time.

[gunr2171]

Right now the bot works on "request/response" system. This means that a user has to initiate an action before the bot will do anything, including refreshing tag data. However, any tag command will cause a refresh if the data has expired, so it's not all that bad. But it is on-demand.

The system you are suggesting is more a "continuous" system, where the bot runs functions all the time (or on a schedule) independent of chat. For example, the bot would auto-refresh tag data every 30 minutes, or on a manual refresh by a chat user.

I would much rather use the continuous system. It would certainly be a big step towards allowing the bot to run 24/7, which is one of the milestones coming up.

Either way, we are still going to have to stop tag commands while a refresh is happening. We would also have the same rate-limiting that you suggest.

[gunr2171]

Well, now we know what happens:

http://chat.stackoverflow.com/transcript/message/22565014#22565014

[gunr2171]

Update: due to "we want to get version 2 out the door", this will not be a feature in version 2.0. However, this feature still has merit and will still be considered.

Tag refreshing is much faster now, so the likelyhood of this happening without it being planned is low.

For when we do develop this it should be a simple check at the start of the command to see if another instance of the command is running.