search

mneudert / instream

InfluxDB driver for Elixir
Apache License 2.0
222 stars 37 forks source link

Hackney error #61

Open agramichael opened 4 years ago

agramichael commented 4 years ago

Ran into this error quite a few times:

** (ArgumentError) argument error
            (stdlib 3.13) :ets.lookup_element(:hackney_config, :mod_metrics, 2)
            /Users/michael/Documents/alchemist/deps/hackney/src/hackney_metrics.erl:27: :hackney_metrics.get_engine/0
            /Users/michael/Documents/alchemist/deps/hackney/src/hackney_connect.erl:75: :hackney_connect.create_connection/5
            /Users/michael/Documents/alchemist/deps/hackney/src/hackney_connect.erl:44: :hackney_connect.connect/5
            /Users/michael/Documents/alchemist/deps/hackney/src/hackney.erl:333: :hackney.request/5
            (stdlib 3.13) timer.erl:166: :timer.tc/1
            lib/instream/connection/query_runner.ex:70: Instream.Connection.QueryRunner.read/3

Solved it by adding a Application.ensure_all_started(:hackney) on startup.

mneudert commented 4 years ago

Are you by any chance using a custom :applications list (or :included_applications) in your project's Mixfile? Or running a Mix.Task?

"By default" the application startup should detect :hackney as a dependency and ensure it is started early enough to not be a problem.

agramichael commented 4 years ago

The app in my umbrella that has :instream as a dependency doesn't have any extra or included applications.

Yeah I expected :hackney to be detected and started by default. Was surprised when ensuring it was started fixed this.

mneudert commented 3 years ago

I somehow managed to construct an umbrella application that can force a startup error: https://github.com/mneudert/instream-issue_61

The example is extremely contrived by sending a request through hackney from a dependency "next" to :instream without directly depending on it (see second to last commit). Adding an entry to :extra_applications fixed the issue (see most recent commit) without having to reorder the dependency tree in the umbrella.

If you are building a release and see the issue you could look at the startup file (i.e. _build/dev/rel/your_app/releases/0.1.0/start.script) to see the application order. The block at the end of the file between {progress,applications_loaded} and {progress,started} might show the actual app trying to send the early request. Ideally all your applications are listed below :hackney, otherwise some more wild testing may be necessary to replicate the problem :thinking: