Guideline to prevent looping!

[Daniel Parker]

I don't know if any of you have thought about this before, but I wanted to bring up the thought.

The web as a programming platform has a large number of non-communicating programmers (users) who don't always know what they're doing. The one bug they can introduce into the system is an infinite loop. Therefore, I believe one of our recommendations should be in regards to detecting and preventing infinite loops.

Here's my thought for a simple prevention:

Every event that is dispatched should have a unique id assigned to it. Every action that is passed on in a chain of webhooks should retain that same event id, so that if any link in the chain receives a descendent reaction of an event it already processed, it can by principle ignore that webhook.

Just puttin' that out there..

- daniel parker -

"You have granted me life and steadfast love, and your care has preserved my spirit." Job 10:12
"The LORD is my chosen portion and my cup . . . indeed, I have a beautiful inheritance." Psalm 16:5-6
"Give what you can ... take nothing back!"

[Jeff Lindsay]

You know, most adaptive systems use feedback loops to be awesome. I don't think we should actively prevent infinite loops. I think we're either trying to avoid infinite *instant* loops that would eat up cpu cycles and network. Luckily this is solved by standard rate limiting. The other thing to avoid is destructive/disruptive cyclic behavior--things like sending you thousands of emails. Again, I think that's up to the design of your system to prevent. Because the event being passed around itself is not doing anything special.

Plus, I think it would be a hard sell to get all POSTs related to some event to maintain an ID. Especially since the conceptual flow may involve going through/using APIs that are not aware of webhooks at all. Say I have a GitHub post-receive hook that runs code that commits changes, which triggers that hook again... there's no way to easily pass an ID in that scenario, and that is more or less how almost all scenarios will be.

-jeff

--
Jeff Lindsay
http://webhooks.org -- Make the web more programmable
http://shdh.org -- A party for hackers and thinkers
http://tigdb.com -- Discover indie games
http://progrium.com -- More interesting things

[Daniel Parker]

You're right on the github example, and there will always be links in the chain here and there known for breaking the chain. But do remember that these ideas are still just tools in a toolkit. You wouldn't throw out the star-shaped screwdriver just because most screws are phillips... The idea is fielded as a technique that could be used, though not always relied upon, to detect at least the blatant kind of infinite loops. But it'd have its holes. The question is, is it a valid and useful tool, or can it be improved upon or replaced?

I guess the more important question though is, do we need a tool for that purpose at all? (Do we care about infinite loops at all?) If so, what kind? And how do we prevent that kind? Or should it simply be left up to the implementation in every case?

- daniel parker -

"You have granted me life and steadfast love, and your care has preserved my spirit." Job 10:12
"The LORD is my chosen portion and my cup . . . indeed, I have a beautiful inheritance." Psalm 16:5-6
"Give what you can ... take nothing back!"

[Jeff Lindsay]

Again, every callback request is just like a regular request which you'd have the same concerns of DoS attacks (effectively what an infinite loop would look like) and these have pretty standard procedures for dealing with. Other than that, it *may* be a valid/useful tool, however until it's validated by an actual instance of the problem and success story of a proper solution, I'm personally under the opinion it's not worth spending any cycles on (other than seeing if people have had problems and what their solution has been).