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

Active Support notifications: spike/design work for an overhaul that will potentially require a major agent version bump #2616

Open
fallwith opened this issue May 1, 2024 · 2 comments
Labels
innovation version: 10.0.0 Next Major Release - Breaking Changes

Comments

@fallwith
Copy link
Contributor

fallwith commented May 1, 2024

As discussed on #2610, #2610's work done to provide an allowlist of Active Support notifications event names really only scratches the surface of what would be possible with a comprehensive notifications instrumentation overhaul. Ruby on Rails is our most significant instrumented library and we use notification subscriptions to power all of our Rails instrumentation. So any work done in this area has a very high return on investment as far as customer value and adoption goes.

At a high level, we can challenge the current siloing of instrumentation based on Rails libraries (one silo per library) and explore a more holistic approach for notifications based instrumentation. Our agent and therefore its silo pattern predates Rails' support for notifications, so it is understandable that the same siloing continued when notifications came along. And certainly there may be more pros than cons to siloing. But we should do some research and develop some proofs of concept for testing that could help us either appreciate or challenge the siloing pattern.

We could explore at least all of the following:

  • Performing subscriptions that apply to multiple Rails libraries, and leaving us with fewer subscriptions overall (saves a bit of memory if nothing else).
  • Revisit our common-across-all-libraries start and stop event processing methods to see if anything more can be done than we are currently accomplishing with basic class inheritance.
  • Permit customers to define allowlists and denylists of either complete or partial event names that would be applicable across all Rails event types for all libraries.
  • Performance benefits that come from more specific subscription patterns than our current "give me all the events for this Rails library" approach taken with each subscription.
@workato-integration
Copy link

@kaylareopelle
Copy link
Contributor

kaylareopelle commented Jul 22, 2024

Related to GTSE: NR-250435 (Internal)

@kaylareopelle kaylareopelle added the version: 10.0.0 Next Major Release - Breaking Changes label Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
innovation version: 10.0.0 Next Major Release - Breaking Changes
Projects
None yet
Development

No branches or pull requests

2 participants