Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initialize NewRelic before Rails' config-initializers #279

Closed
wants to merge 2 commits into from

Conversation

tonyta
Copy link
Contributor

@tonyta tonyta commented Dec 23, 2017

Before, the initializer for NewRelic did not specify any ordering. In some situations, Rails will order its load_config_initializers before NewRelic's newrelic_rpm.start_plugin. This is a problem if NewRelic is called in a config-initializer (e.g. when defining method tracers) and will output the following warning:

Agent unavailable as it hasn't been started.

This change ensures that newrelic_rpm.start_plugin always gets loaded before config-intiializers are.

The problem is detailed and the fix is demonstrated here: tonyta/newrelic_warning#1


An unrelated dependency loading issue is fixed in cc9f74a to allow tests to pass.

Before, the initializer for NewRelic did not specify any ordering. In
some situations, Rails will order its load_config_initializers before
NewRelic's newrelic_rpm.start_plugin. This is a problem if NewRelic is
called in a config-initializer (e.g. when defining method tracers) and
will output the following warning:

  Agent unavailable as it hasn't been started.

This change ensures that newrelic_rpm.start_plugin always gets loaded
before config-intiializers are.
Multiverse::Suite#ordered_ruby_files depends on Dir.glob, which does not
guarantee order. Since TestWorker depends on SidekiqServer, the tests
will fail is the former is loaded before the latter.

    >> Dir[File.join("test/multiverse/suites/sidekiq", '*.rb')]
    => ["test/multiverse/suites/sidekiq/test_worker.rb",
     "test/multiverse/suites/sidekiq/sidekiq_server.rb",
     "test/multiverse/suites/sidekiq/sidekiq_instrumentation_test.rb",
     "test/multiverse/suites/sidekiq/after_suite.rb",
     "test/multiverse/suites/sidekiq/test_model.rb"]

Adding an explicit require before TestWorker will circumvent this issue
while also declaring the explicit dependency.
@tonyta
Copy link
Contributor Author

tonyta commented Dec 27, 2017

The changes between 4b3c200 and cc9f74a don't seem to account for the new test failures (which might be related to issues on the Rubygems server). The failures are likely nondeterministic and could probably just be retried. ¯\(ツ)

Hope this helps!

@mwear mwear self-assigned this Dec 27, 2017
@tonyta
Copy link
Contributor Author

tonyta commented Jan 5, 2018

Hi @mwear! Anything blocking this? Anything I can do to help?

@mwear
Copy link
Contributor

mwear commented Jan 6, 2018

Hi @tonyta. Thanks for checking in. We've pulled this branch into our private repo and are currently discussing it. We are mostly in favor of the change as it makes the point at the which the agent is started better defined. There is a small amount of concern about changing things around agent startup, especially if there are users relying on some of the idiosyncrasies around how it is currently initialized. That's mainly the source of our discussions for now.

We'll keep you updated on the status. Also, I wanted to give a brief run down of how we handle public PRs as it is likely a slightly different workflow from other projects you may have contributed to. We do not merge PRs directly to the public repo. We first pull them into our private repo, discuss the changes, and if we accept them, we'll merge it into our development branch on our private repo. At that point we would put an accepted label on the public PR. Your changes would make it to the public repo when we push out our next release.

Thanks for your submission and we'll be in touch if we need anything.

@mwear mwear added accepted and removed in review labels Jan 19, 2018
@mwear
Copy link
Contributor

mwear commented Jan 19, 2018

Hi @tonyta. Thanks for the contribution and the patience. This will be going into our next release. While we don't have an exact date for you, I'd expect to see it in the next couple of weeks. Thank you!

@mwear
Copy link
Contributor

mwear commented Jan 31, 2018

Hi @tonyta. I wanted to let you know that your changes have been integrated into version 4.8.0 of the agent, which was released this morning. Thank you for your contribution!

@mwear mwear closed this Jan 31, 2018
@tonyta
Copy link
Contributor Author

tonyta commented Jan 31, 2018

Thanks @mwear! 💛💚💙💜❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants