At the time of my last post, there were a few outstanding issues that I wanted to address in the code of pg_webhooks. I’ve addressed three of them this week.
There wasn’t actually a route to unsubscribe from a channel, so I added that shortly after the initial release.
Another key shortcoming was that the original version of the code didn’t really do any work to ensure that the resulting payload sent to the callback was always JSON. The PostgreSQL NOTIFY statement can return any arbitrary string, so I added some logic to coerce it into a JSON document before firing the callback. I’m certain there are numerous ways in which this is still fragile, but I’ll circle back to it.
Finally, I added some failure management. If a callback returns a non-200-series status code for three consecutive calls, then the subscription is disabled. The only way to fix that is for an administrator to update the database. This is by design to force some communication between the owner of a faulty callback host and the admin of the system running pg_webhooks. I don’t have plans to make this resolution any easier.
Next up will be runtime subscriber management, which was partially addressed by failure management, but still needs some work.
I also plan to add some logic to ensure the payloads include some kind of key or hash that can be used by a callback host to ensure the incoming payload actually originated from the pg_webhooks host. I’m still sketching that out, but an issue will go up soon.
