notifico
notifico copied to clipboard
TkTech
Transparency into current system status
How about a way to see whether the system is supposed to be down, or whether or not bots are joined to the channels, or if there's a queue that users will have to wait until their commits are processed?
I am not seeing bots logged in to their usual channels even though commits are being pushed, so it's possible that the problem is on github's end, but it's hard to tell where the problem is occurring from my perspective.
Absolutely, that's one of the goals for the new bot framework. Unfortunately until the bots are improved this can't be implemented on the front end. We used to have "BotEvents" (the table is still there) which would record errors, connections, and such but it was horrible to maintain and poorly done. The new bot server is entirely event based and exposes those events over HTTP and Redis PubSub, which will make integration much easier and scalable to multiple bot servers (a future requirement do to connection limits (max channels, max conns) per IP on most networks)
As an example, at the moment I don't see any commit messages sent into channels. I also don't see any bots logged on. I am using freenode and another no-name network that probably isn't blocking Notifico, so it's most likely not because of a ban.
I used the wonderful http://requestb.in/ service to generate a url, then told github to treat that url as a webhook, clicked applied or update or whatever, then clicked test. Requests are definitely being sent from github to requestb.in for webhooks.
But I have no insight into what's wrong on Notifico's end at all.
On a related note, grove.io has been having trouble with their github git commit hooks for a few weeks now. They claim that the problem is on github's end-- something about their hooks being broken somehow. But since I can see webhooks working just fine when I insert the requestb.in endpoint, I am inclined to think github is working.
Huh, some of the commits got sent multiple hours later. Maybe there can be a blurb about a delay existing? I didn't even know.
Yesterday multiple issues were resolved with stability and the backlog in the queue was purged. Notifico should be much more reliable in your channel now.
Outbound messages are stored in a redis queue and Notifico always attempts to deliver them, even if it was down or couldn't connect for a few hours. A TTL might be a good idea (if the message has been undelivered for 24 hours don't bother trying again?)
Ah cool, thanks for the update. Yeah, maybe messages delayed for more than 6 hours (or some other number) should be modified to mention the delay? I'll consider digging in to contribute this sort of change. (Can't do it right this moment.)