4 ms·

It seems that Github should eventually retry delivery on transient faults, like connection time outs or 500 errors.

• xur17 11y ago
  I'm surprised to see that they don't - it seems standard to retry on failure, waiting longer and longer between each attempt. Some sort of pubsub queue would be awesome - pull (or have them pushed), and process them on demand. If something breaks, retry when you want.
  • devbug 11y ago
    I'd love an open-source appliance that lets me turn webhooks (and polling APIs) into a kind of pub-sub. Being able to inspect, modify, and run events would be an "immediately use this" feature set. It would be something I would pay for to not have to host myself, but iff there's a clear migration path, i.e. it's open-source.
    • debacle 11y ago
      Huginn?
    • smetj 11y ago
      Wishbone could do that http://wishbone.readthedocs.org/en/latest/index.html http://wishbone.readthedocs.org/en/latest/index.html Some example articles: - http://smetj.net/processing_webhooks_using_wishbone_part_1.html http://smetj.net/processing_webhooks_using_wishbone_part_1.h... - http://smetj.net/processing_webhooks_using_wishbone_part_2.html http://smetj.net/processing_webhooks_using_wishbone_part_2.h...
  • athenot 11y ago
    Those are basically the semantics of SMTP delivery. Come to think of it, that protocol could make more sense than HTTP for asynchronously messaging entities. I love the simplicity of webhooks, but sometimes it's nice to abstract away the redelivery mechanism without having to set up one's own broker. FWIW, that's the underlying protocol used in BlueButtonPlus[0], the proposed method for exchanging healthcare information. [0] http://bluebuttonplus.org/transmit-using-direct.html http://bluebuttonplus.org/transmit-using-direct.html
• debacle 11y ago
  You should never assume that a third-party implements HTTP properly by default.