* Use test matrix from file
* Only check formatting on specific Elixir version
* Use latest patch version of each Elixir/OTP release in test matrix
* Test on Elixir 1.15 and OTP 26
* Run formatter on opentelemetry_httpoison
* Run formatter on opentelemetry_phoenix
* Run formatter on opentelemetry_tesla
* Fix building opentelemetry_ecto on Elixir 1.15
Upgraded deps to fix ssl_verify_fun not compiling
* Fix building opentelemetry_dataloader on Elixir 1.15
Upgraded deps to fix ssl_verify_fun and ecto_sql not compiling
* Upgrade opentelemetry_finch to build on Elixir 1.15
* Upgrade opentelemetry_httpoison deps to build on 1.15
* Upgrade opentelemetry_nebulex to build on Elixir 1.15
* Upgrade opentelemetry_oban to build on Elixir 1.15
* Upgrade opentelemetry_phoenix deps to build on 1.15
* Upgrade opentelemetry_redix deps to build on 1.15
* Fix warning about <> being ambiguous
* Fix assertion on attributes keys
These are always atoms, not strings.
* Upgrade ssl_verify_fun in opentelemetry_telemetry
* Deterministically sort keys before asserting in tests
* Upgrade opentelemetry_process_propogator to build on Elixir 1.15
* Run mix format on opentelemetry_process_propogator
* Assert keys are atoms, not strings
* Use matrix.os to define runs-on parameter
* Pin test matrix to specific OTP + Elixir versions
* Run formatter on telemetry and process_propagator
* Run formatter over opentelemetry_phoenix
---------
Co-authored-by: Tristan Sloughter <t@crashfast.com>
Default exporter immediately attempts on start connect to
`:otel-collector` default port. As we don't have any collector running
on our test environment, this results in a few warnings. That's not an
issue in itself, as code immediately switches to another export, but
creates a lot of noise.
This patch moves the exporter setup to `config/test.exs`, essentially
removing the need to restart opentelemetry applicationn for each test
case. The only work setup blocks do is update the exporter's target pid.
The processor was changed to simple mode, available now, which also remove
another vector of (unlikely but theoretically possible) race-conditions.
There is an edge case, if you use `forward/4` and use Plug.ErrorHandler,
then when an exception reaches the outer router, then Plug.send_resp
will be called, triggering `[:phoenix, :endpoint, :stop]`, and the span
will be gone by the time the outer router gets the exception. This
causes this telemetry handler to crash and be detached.
Sequence of events:
- [:phoenix, :endpoint, :start]
- [:phoenix, :router_dispatch, :exception] (inner router)
- [:phoenix, :endpoint, :stop]
- [:phoenix, :router_dispatch, :exception] (outer router) ** here there is no span, crashes
Derek Kraan
Tom Taylor
Yordis Prieto
Andrew Rosa
Bryan Naegele
Ho-Yon Mak
Timmo Verlaan