Toxiproxy 2.0 RFC about toxiproxy HOT 11 CLOSED

What's the plan for ensuring the toxic has finished sending output after being interrupted, and before the connections are changed? Wait for Pipe() to return?

Also 👍 for the API. Have you thought about allowing control of the toxic ordering? That might be useful in some cases, but maybe not enough to be worth the extra complexity.

from toxiproxy.

stub.Interrupt() will not return until Pipe() has returned now, so we are guaranteed that either the data is sent or it won't be until we resume.

Another thing for the implementation:
I'd like to wrap toxics in a struct with some extra fields (like name) so that we can simplify the Toxic interface to just the Pipe() function.
This means much less boilerplate code in the toxic definitions.

from toxiproxy.

🆒

from toxiproxy.

Wouldn't it be more restful to do:

POST /proxies/{proxy}/{up|down}stream/toxics

But only allow certain names?

from toxiproxy.

👍 @sirupsen That means it also exactly matches how proxies are created.

from toxiproxy.

👍 to the API and design

from toxiproxy.

Another interpretation to the API would be that all the toxics are created on the resource by default, and you have to do a PUT to update them. Would that make more sense?

from toxiproxy.

Missed this before (maybe because it was edited in after): toxic order is determined by the order toxics are created in, since we'll always append to the end of the chain. In the general use case, this works well since I don't see a need to reorder toxics without removing them all first.

I think the idea of adding/removing toxics vs enabling/disabling is what we want. It seems to be what people are expecting, and it will scale better if/when we have many types of toxics (I expect there will end up being many protocol-aware toxics)

from toxiproxy.

@sirupsen PUT semantics are to replace the whole object, while in this case it would be more convenient to do an incremental update.

from toxiproxy.

👍

from toxiproxy.

We need to remember to remove the toxiproxy binary that doesn't have a -server suffix.

from toxiproxy.