It would be cool if we could specify different auth options per connection. What do you think about making the auth option optionally take a function that takes the client index and a sender boolean?

const instance = anger({
  ...
  auth: (i, sender) => {

    return { headers: { ... } }
  },
  ...
})

I think if a connection error is received, it should be the test over, the error should be emitted and existing connections torn down. This code never runs though because no errors are propagated from steed.each(). Maybe it should be steed.map() instead?

An alternative to stopping the test is to allow the test to continue, recording the error event and letting it time out when ultimately all the expected responses aren't received. In the end reporting the number of connection errors and the number of subscription errors.

We should support custom options to be passed to each nes.Client

cc @mtharrison

I would like to set a timeout option that applies to each sender request, within which if all expected responses haven't been received we continue to the next trigger or complete if all done.

The existing tail option kind of does this if there's no more requests to be sent:

tail: 200
requests: 1
senders: 1
connections: 3

----------x                        0ms (request sent)
          -------x                 +80ms receive response                                   
          -----------x             +130ms receive response
          -------------------!     +200ms tail is triggered, 1 missing response

However if you have >= 2 requests and 1 sender it never gets triggered, so it hangs forever:

tail: 200
requests: 2
senders: 1
connections: 3

----------x                                 0ms (request sent)
        -------x                            +80ms receive response                                   
        -----------x                        +130ms receive response
        -------------------!----Infinity    No timeout, we wait forever

In the case above, I'd like to timeout after 200ms, mark the response as missing and start the next request.

timeout: 200
requests: 2
senders: 1
connections: 3

----------x                                 0ms (request sent)
        -------x                            +80ms receive response                                   
        -----------x                        +130ms receive response
        -------------------!                Timeout, 1 missing response
                           x                Next request triggered...

See #16

cc @davidmarkclements

https://www.npmjs.com/package/try-again
https://www.npmjs.com/package/recovery

Currently a batch of messages are triggered, and then the tester wait fot all to complete. This is extremely stressful for an application.
I think a more realistic test is to send all the messages are the beginning, but then trigger a new one once the previous one has completed. In this way we can reproduce a more stable load, rather than a series of spikes.

Perhaps we should have a mode that doesn't actually send any requests, it just keeps adding and removing clients - and also, simply add clients (no removing) until the breaking point