Force full crash of Bandit in case of error

Questions / Help
1

Hello,

In our tests we are mocking http servers to assert different things about sent http requests. This is the child spec that we use:

      Supervisor.child_spec(
        {Bandit,
         plug: {MockablePlug, spec},
         scheme: :http,
         port: 0,
         thousand_island_options: [num_acceptors: 10, num_connections: 2]},
        id: {__MODULE__, spec.id}
      )

There is nothing notable about MockablePlug except that it rescues exceptions to log different things, and then reraises them.

We use that spec with start_link_supervised! in order to fail our test if our ad-hoc http server fails. The problem we face is that there is a layer of supervision that prevents our test from failing.

I would like to know if there is a builtin mechanism to force the whole Bandit instance to crash when the http handler does. I understand that this is the opposite of what we would generally want so I would not be surprised if there is not.

The handlers seem to be dynamically started so I cannot manually link it to the test process before calling it.

Thank you :slight_smile:

(pinging @mtrudel )

2

Crashing an individual handler is generally not meant to propagate to the whole server, so this behavior probably expected.

I guess you could register a telemetry handler to catch handlers crashing from exceptions.

3

Telemetry will be cumbersome as we have multiple concurrent tests. I’ll try :slight_smile: Edit: well the handlers will not be executed by the test process so it boils down to manually linking too.

I am trying Bypass right now but that will make use rewrite a lot of tests. No big changes though.

4

There’s no direct way to do that - if you really wanted to, you could run your tests sync & appeal to a combo of Bandit.PhoenixAdapter — Bandit v1.4.2 and ThousandIsland — Thousand Island v1.3.5 in a rescue block within your Plug, but that’s pretty hacky.

If I understand your goals properly, you could just asset inside your plug; it won’t come up as a proper test failure but (assuming you’re not capturing logs) it’ll still fail and produce useful output (just in the form of a stack trace). I use this eg: for testing Plug conformance at bandit/test/bandit/http2/plug_test.exs at main · mtrudel/bandit · GitHub

5

Yeah I see the logged errors, plus the fact that I rescue and log useful informations before re-raising helps, but the test still passes, and that is really the problem.

The plug receives the pid of the test, passed as options from the setup of all of that, but even if I link the plug process to the test process, it does not fail the test (unless I sleep in the test for a couple milliseconds) because the test terminates too fast.

The easiest thing I do right now is send a message from the plug process to the test process after all the assert(), and the test uses assert_received to it can fail. It works but it’s annoying. I’m trying Bypass for the new test I’m working on, it seems to properly handle my case (which is really: I can’t fail the production code by returning something wrong from the mock plug, as the production code does not care about the http response, so I can only fail from the plug handler).

Thanks anyway, and thanks for Bandit, it works great :slight_smile: