ActionView::Template::Error: undefined method `identifier'

[navidemad]

Description

Running view_component with recent change ViewComponent/view_component@451543a#diff-b69c75ffd85596e0b5fca1327059ecf3b2930f3f77004c78a268fa85e8ec8d9eL601

Makes the following error in our production server:
ActionView::Template::Error: undefined method identifier' for class LinkComponent`

Expected Behavior

Your method metric_path manage already if the identifier is not set to "component" but the problem is coming from in render_in_with_tracing that is doing self.class.identifier

Your Environment

ruby 3.3.4 (2024-07-09 revision be1089c8ec) +YJIT [arm64-darwin23]
gem view_component (3.15.0)
gem newrelic_rpm (9.13.0)

For Maintainers Only or Hero Triaging this bug

Suggested Priority (P1): We had to pin to pin view_component to 3.14.0 otherwise we were getting a lot of errors

[workato-integration]

https://new-relic.atlassian.net/browse/NR-319785

[joelhawksley]

👋🏻 this method should never have been used, as it was marked @private and not documented. I've re-introduced it in https://github.com/ViewComponent/view_component/releases/tag/v3.15.1 but will remove it in a coming minor release.

[fallwith]

Closing, as #2870 has been merged. For anyone coming across this issue in the future:

• The fair point about private API usage is addressed in Safety guard when the self.class is not responding to method identifier #2870 (comment)
• PR Safety guard when the self.class is not responding to method identifier #2870 which accompanied this issue has been merged and will be released in the next agent version
• Follow-up work related to Safety guard when the self.class is not responding to method identifier #2870 (comment) has been captured with ViewComponent: consider consuming ActiveSupport notifications, audit our instrumentation for private API usage #2872 and ViewComponent: evaluate the way that we obtain the component class identifier #2874

[ZilvinasKucinskas]

This issue brought the whole production down (every single page). newrelic_rpm is disabled by default in development and test environments, so it was impossible to catch.

How can we enable newrelic_rpm in a test environment but not send data to it? It would be helpful to catch such issues in a test environment.

[fallwith]

Hi @ZilvinasKucinskas (cc @hasghari). We are sorry for the poor experience that this issue caused for you.

We endeavor to make the agent's instrumentation logic bullet-proof so that even when it crashes it doesn't impact the original Ruby library's functionality, but this error unfortunately did impact the core functionality.

The original issue (now fixed in the latest available New Relic Ruby agent gem, v9.14.0) was caused by using newrelic_rpm at v9.13.0 or older in combination with a version of view_component at v3.15.0 or newer.

We appreciate the unfortunate surprise element of your situation that resulted from not introducing newrelic_rpm in any dev or test environments.

Here are 2 ways to potentially prevent future similar issues with newrelic_rpm going forward:

1. Use a staging environment

   • In the Ruby app's Gemfile.lock file, lock all gem versions down to the exact versions that will be used in production
   • Using a staging environment, deploy newrelic_rpm alongside those exact versions
   • Send at least a small amount of data through the app to ensure that all New Relic library instrumentation functions properly
   • After everything looks good, deploy all of the exact same gem versions to production

2. Test with New Relic in a dev/test environment without sending (and being charged for) any data to New Relic

   • Introduce the newrelic_rpm gem and its configuration to the desired environment
   • In newrelic.yml, set monitor_mode: false to disable monitor mode and cause the agent to not report data to New Relic
   • Note that newrelic.yml by default has dedicated development and test environment sections. The monitor_mode: false setting can be applied to one of these environment configurations without impacting the default settings used in production.

How can we enable newrelic_rpm in a test environment but not send data to it?

I think option 2 best addresses this question. Hopefully option 1 is useful to some as well.

[ZilvinasKucinskas]

I will share the default newrelic.yml. Both development and test environments already has monitor_mode: false set. However, in both environments everything works without issues. Only production crashes in that case.

@fallwith Would you mind checking what's missing?

Sample newrelic.yml

#
# This file configures the New Relic Agent.  New Relic monitors Ruby, Java,
# .NET, PHP, Python, Node, and Go applications with deep visibility and low
# overhead.  For more information, visit www.newrelic.com.
#
# Generated October 28, 2022
#
# This configuration file is custom generated for NewRelic Administration
#
# For full documentation of agent configuration options, please refer to
# https://docs.newrelic.com/docs/agents/ruby-agent/installation-configuration/ruby-agent-configuration

common: &default_settings
  # Required license key associated with your New Relic account.
  license_key: <%= Rails.application.credentials.dig(:new_relic, :license_key) %>

  # Your application name. Renaming here affects where data displays in New
  # Relic.  For more details, see https://docs.newrelic.com/docs/apm/new-relic-apm/maintenance/renaming-applications
  app_name: 'APPLICATION'

  distributed_tracing:
    enabled: true

  # To disable the agent regardless of other settings, uncomment the following:

  # agent_enabled: false

  # Logging level for log/newrelic_agent.log
  log_level: error

  application_logging:
    # If `true`, all logging-related features for the agent can be enabled or disabled
    # independently. If `false`, all logging-related features are disabled.
    enabled: true
    forwarding:
      # If `true`, the agent captures log records emitted by this application.
      enabled: true
      # Defines the maximum number of log records to buffer in memory at a time.
      max_samples_stored: 10000
    metrics:
      # If `true`, the agent captures metrics related to logging for this application.
      enabled: true
    local_decorating:
      # If `true`, the agent decorates logs with metadata to link to entities, hosts, traces, and spans.
      # This requires a log forwarder to send your log files to New Relic.
      # This should not be used when forwarding is enabled.
      enabled: false

# Environment-specific settings are in this section.
# RAILS_ENV or RACK_ENV (as appropriate) is used to determine the environment.
# If your application has other named environments, configure them here.
development:
  <<: *default_settings
  app_name: 'APPLICATION (Development)'
  monitor_mode: false

test:
  <<: *default_settings
  # It doesn't make sense to report to New Relic from automated test runs.
  monitor_mode: false

staging:
  <<: *default_settings
  app_name: 'APPLICATION (Staging)'
  monitor_mode: false

production:
  <<: *default_settings

[fallwith]

@ZilvinasKucinskas your config looks fine to me.

In your dev/test environments, as long as you see "Installing ViewComponent instrumentation" in the New Relic agent log then the ViewComponent code from the agent is running.

As long as the exact same version of the Ruby library (view_component in this case) is used in test and production and the same rendering logic is involved, the same New Relic code paths should be involved. But if different gem versions are involved (for example: view_component v3.14.0 in test and view_component v3.15.0 in production), then the behavior might be different.

[ZilvinasKucinskas]

@fallwith I have just tested with gem "view_component", "= 3.15.0" and gem "newrelic_rpm", "= 9.13". The error only happens if monitor_mode: true (default). As I understand, it means New Relic would be sending data in those environments, right? It would be ideal to trigger errors but skip sending data.

[fallwith]

I see, @ZilvinasKucinskas. I apologize for giving you information that did not work. I was under the impression that agent_enabled: false would gatekeep the view_component instrumentation usage and monitor_mode: false would gatekeep the billable data reporting to New Relic. Therefore I thought if you used agent_enabled: true (the default) and monitor_mode: false (via an environment specific override), it would give you what you wanted - test the agent's view_component logic without sending data to New Relic.

I have created a new issue #2882 to track this further. Your desired scenario of active instrumentation without billing sounds great to me, and hopefully we can support that in future either with monitor_mode or some other way.

[ZilvinasKucinskas]

Thanks for creating an issue for it, @fallwith! 🙇‍♂️ In the test environment, many Rails projects are usually using WebMock and disable external connections. Therefore, this mode would be highly valuable! I guess on your end you would just "ignore" API calls to New Relic and stub them to always be successful without ever being called.