remove activate() from the plugin API (#1569)

* remove activate() from the plugin API

fixes: #1549

also remove plugin_muts() from supergraph_service since the activate
functionality was the only consumer of this API.

NEXT_CHANGELOG.md

@@ -27,6 +27,14 @@ By [@USERNAME](https://github.com/USERNAME) in https://github.com/apollographql/
 
 ## ❗ BREAKING ❗
 
+### Remove `activate()` from the plugin API ([PR #1569](https://github.com/apollographql/router/pull/1569))
+
+Recent changes to configuration reloading means that the only known consumer of this API, telemetry, is no longer using it.
+
+Let's remove it since it's simple to add back if later required.
+
+By [@garypen](https://github.com/garypen) in https://github.com/apollographql/router/pull/1569
+
 ### QueryPlan::usage_reporting and QueryPlannerContent are private ([Issue #1556](https://github.com/apollographql/router/issues/1556))
 
 These items have been removed from the public API of `apollo_router::services::execution`.
@@ -36,4 +44,4 @@ By [@SimonSapin](https://github.com/SimonSapin) in https://github.com/apollograp
 ## 🚀 Features
 ## 🐛 Fixes
 ## 🛠 Maintenance
-## 📚 Documentation
+## 📚 Documentation

apollo-router/src/plugin/mod.rs

@@ -165,10 +165,6 @@ pub trait Plugin: Send + Sync + 'static + Sized {
     /// plugins are registered.
     async fn new(init: PluginInit<Self::Config>) -> Result<Self, BoxError>;
 
-    /// This is invoked after all plugins have been created and we're ready to go live.
-    /// This method MUST not panic.
-    fn activate(&mut self) {}
-
     /// This service runs at the very beginning and very end of the request lifecycle.
     /// Define supergraph_service if your customization needs to interact at the earliest or latest point possible.
     /// For example, this is a good opportunity to perform JWT verification before allowing a request to proceed further.
@@ -216,10 +212,6 @@ fn get_type_of<T>(_: &T) -> &'static str {
 /// For more information about the plugin lifecycle please check this documentation <https://www.apollographql.com/docs/router/customizations/native/#plugin-lifecycle>
 #[async_trait]
 pub(crate) trait DynPlugin: Send + Sync + 'static {
-    /// This is invoked after all plugins have been created and we're ready to go live.
-    /// This method MUST not panic.
-    fn activate(&mut self);
-
     /// This service runs at the very beginning and very end of the request lifecycle.
     /// It's the entrypoint of every requests and also the last hook before sending the response.
     /// Define supergraph_service if your customization needs to interact at the earliest or latest point possible.
@@ -253,11 +245,6 @@ where
     T: Plugin,
     for<'de> <T as Plugin>::Config: Deserialize<'de>,
 {
-    #[allow(deprecated)]
-    fn activate(&mut self) {
-        self.activate()
-    }
-
     fn supergraph_service(&self, service: supergraph::BoxService) -> supergraph::BoxService {
         self.supergraph_service(service)
     }

apollo-router/src/router_factory.rs

@@ -89,16 +89,7 @@ impl SupergraphServiceConfigurator for YamlSupergraphServiceFactory {
             builder = builder.with_dyn_plugin(plugin_name, plugin);
         }
 
-        // We're good to go with the new service. Let the plugins know that this is about to happen.
-        // This is needed so that the Telemetry plugin can swap in the new propagator.
-        // The alternative is that we introduce another service on Plugin that wraps the request
-        // at a much earlier stage.
-        for (_, plugin) in builder.plugins_mut() {
-            tracing::debug!("activating plugin {}", plugin.name());
-            plugin.activate();
-            tracing::debug!("activated plugin {}", plugin.name());
-        }
-
+        // We're good to go with the new service.
         let pluggable_router_service = builder.build().await?;
 
         Ok(pluggable_router_service)

apollo-router/src/services/supergraph_service.rs

@@ -331,10 +331,6 @@ impl PluggableSupergraphServiceBuilder {
         self
     }
 
-    pub(crate) fn plugins_mut(&mut self) -> &mut Plugins {
-        &mut self.plugins
-    }
-
     pub(crate) async fn build(self) -> Result<RouterCreator, crate::error::ServiceBuildError> {
         // Note: The plugins are always applied in reverse, so that the
         // fold is applied in the correct sequence. We could reverse

docs/source/customizations/native.mdx

@@ -89,10 +89,6 @@ impl Plugin for HelloWorld {
         Ok(HelloWorld { configuration: init.config })
     }
 
-    /// This is invoked after all plugins have been created and we're ready to go live.
-    /// This method MUST not panic.
-    fn activate(&mut self);
-
     // Only define the hooks you need to modify. Each default hook
     // implementation returns its associated service with no changes.
     fn supergraph_service(
@@ -242,7 +238,7 @@ There is no sequencing for plugin registration, and registrations might even exe
 
 ### Activate
 
-When the router is ready to start serving requests, it calls each plugin's `activate` method. Plugins are started in the same order they're declared in your [YAML configuration file](../configuration/overview/#yaml-config-file).
+Plugins are started in the same order they're declared in your [YAML configuration file](../configuration/overview/#yaml-config-file).
 
 Note that if a plugin is registered but is _not_ listed in the configuration file, the router does _not_ call `startup` on it. If any plugin fails to start, the router terminates with helpful error messages.