oguzbilgener / noxious Goto Github PK

This is really cool, thanks for writing this!

Is your feature request related to a problem? Please describe.
I'm trying to test some client software that currently work son Linux, but I'd like to support Windows. We currently use toxiproxy docker containers to run our integration tests on Linux; however, this won't work on our Github Actions-based CI for Windows, since it doesn't support Linux containers, and getting a toxiproxy windows container seems like a tall order.

Describe the solution you'd like
It would be great if we could cargo install noxious-server in our CI, since this should create a windows-compatible build, and our CI already uses Rust-based infrastructure for most everything else.

Describe alternatives you've considered
We could clone the repo in our CI and perform the build then.

Additional context
I haven't tested noxious on Windows, so I suppose I'm not totally confident that this will be a silver bullet. I'm happy to try it though.

Is your feature request related to a problem? Please describe.
In my integration tests, I'd like to produce chaos at the TCP layer, but also at the HTTP layer.

Describe the solution you'd like
I'm wondering how you would feel about introducing the concept of HTTP toxics, possibly under a feature flag. I haven't looked too closely at your architecture/implementation yet, but possibly these could consume the entire input stream to a buffer and attempt to parse them as an http::Request.

Describe alternatives you've considered
To solve right now this I've written a very small axum proxy server with middleware that randomly returns early with 503 errors, and we chain this with noxious to produce the desired result.

Additional context
This idea may be a nonstarter, since I think it doesn't play very nicely at all with the directionality approach currently present.

Seems like there's a similar issue in the toxiproxy repo: Shopify/toxiproxy#50

Looks like the Toxiproxy project is alive and actively maintained again! They recently added a new type of toxic, reset peer. It would be great to implement it in noxious too.

Is your feature request related to a problem? Please describe.
I'm currently invoking noxious-server via std::process::Command in a Rust module in my CI. This mostly works great!

I did have some issues though when debugging timing of the process coming up and successfully binding to a port, then also ensuring it is reliably killed.

Describe the solution you'd like
It might be nice to make the noxious-server package both a library and a binary, where the binary is a thin wrapper. I'm thinking that in CI, I'd have a choice to something something tokio::spawn(noxious_server.serve(...))

Describe alternatives you've considered
This isn't strictly required, and it does increase API surface of the package.

Is your feature request related to a problem? Please describe.
It's slightly inconvenient to configure toxics after-the-fact with the client when proxies can be configured using a config file.

Describe the solution you'd like
This would be a clear departure from toxiproxy, but I wonder if it would make sense to allow creation of toxics via configuration as well.

Describe alternatives you've considered
None. The status quo works well.