Coprocessor hook for connectors request/response stages by andrewmcgivery · Pull Request #8869 · apollographql/router

andrewmcgivery · 2026-02-06T00:58:21Z

You can now configure a coprocessor hook for the ConnectorRequest and ConnectorResponse stages of the Router lifecycle.

coprocessor:
  url: http://localhost:3007
  connector:
    all: 1
      request:
        uri: true
        headers: true
        body: true
        context: all
        service_name: true
      response:
        headers: true
        body: true
        context: all
        service_name: true

Checklist

Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.

Exceptions

Note any exceptions here

Notes

It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
A lot of (if not most) features benefit from built-in observability and debug-level logs. Please read this guidance on metrics best-practices. ↩
Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩

apollo-librarian · 2026-02-06T00:58:30Z

✅ Docs preview ready

The preview is ready to be viewed. View the preview

File Changes

0 new, 2 changed, 0 removed

* graphos/routing/(latest)/customization/coprocessor/index.mdx
* graphos/routing/(latest)/customization/coprocessor/reference.mdx

Build ID: 9b4ba4156a72ca4a0aeab67b
Build Logs: View logs

URL: https://www.apollographql.com/docs/deploy-preview/9b4ba4156a72ca4a0aeab67b

…oprocessor

… id passing to response, proper body modification in response

…oprocessor

BrynCooke · 2026-02-10T09:04:25Z

+    tracing::debug!(?payload, "externalized output");
+    let start = Instant::now();
+    let co_processor_result = payload.call(http_client, &coprocessor_url).await;
+    *executed = true;


I'd have to trace through what this is used for. If the request is aborted do we record anything?

Not sure, this is the same logic that exists on the other lifecycle stages so I replicated what was already there. 😅

worth a comment on what executed is for so that we don't accidentally remove it; here's what's in coprocessor/supergraph.rs:

// Indicate the stage was executed to raise execution metric on parent

the parent bit is important for future developers

oh, in reply to @BrynCooke: if the request errors out we emit an error; if the request executes (ie, that bool above stays true), we record a metric (whether it succeeded or failed), but I don't see a metric emitted specifically for coprocessor request failures (probably because they get the same visibility normal request errors get? not sure)

smyrick · 2026-02-11T05:05:50Z

I did some duplicate work here but this works for both subgraphs and connectors as well as the top level router http hook: #8874

aaronArinder · 2026-02-12T15:22:06Z

-register_plugin!(
+register_private_plugin!(


what's behind teh change to a private plugin?

The connector tower layers are currently only hooked up to the private plugin interface, not the public plugin interface.

My assumption (though I 100% could be wrong here) is that coprocessors are a "private"/internal plugin anyways so this shouldn't have any impact... but again, could be wrong there.

There is some ask from customers to move the connector tower layers to the public interface but that would be a larger undertaking so if possible, I'd prefer to do that in a separate PR.

aaronArinder · 2026-02-12T15:28:45Z

-impl Plugin for CoprocessorPlugin<HTTPClientService> {
+impl PluginPrivate for CoprocessorPlugin<HTTPClientService> {


why the switch to private?

aaronArinder · 2026-02-12T16:07:08Z

+coprocessor:
+  url: http://localhost:3007
+  connector:
+    all:


not sure I see why we'd want an all layer between the req/res? eg, SupergraphStage just has req/res without the all layer--any reason why we shouldn't keep that same structure?

looking at the integration tests, it looks like this might be a way to have connector-specific overrides? noticing structural similarities to how subgraph is handled

You should be comparing this entire PR to subgraph, not supergraph. The connectors_request layer is equivalent to the subgraph layer. If you look at subgraph coprocessors, they currently have all and I believe the idea was to eventually allow for per-subgraph configuration, but that was never implemented.

But yes, the idea here is that we're leaving open the ability to override for specific connector sources, but currently are not implementing that in this PR. (all connectors config has this pattern of all and the ability to override per source).

aaronArinder · 2026-02-12T16:08:01Z

+#[serde(default)]
+pub(super) struct ConnectorStages {
+    #[serde(default)]
+    pub(super) all: ConnectorStage,


code reference for the all layer mentioned in the changeset comment; this could reflect the SupergraphStage struct's fields to keep the same structure, unless there's a reason it should be different

Per above, you should be comparing this entire PR to subgraph, not supergraph. The connectors_request layer is equivalent to the subgraph layer.

aaronArinder · 2026-02-12T16:09:47Z

+/// What information is passed to a connector request stage
+#[derive(Clone, Debug, Default, Deserialize, PartialEq, JsonSchema)]
+#[serde(default, deny_unknown_fields)]
+pub(super) struct ConnectorRequestConf {


no sdl? what's the reason for excluding it? cf. the supergraph coprocessor's req/res handling

Per above, you should be comparing this entire PR to subgraph, not supergraph. The connectors_request layer is equivalent to the subgraph layer.

aaronArinder · 2026-02-12T16:44:15Z

+    // unwrap is safe here because validate_coprocessor_output made sure control is available
+    let control = co_processor_output.control.expect("validated above; qed");


I know we do this elsewhere, but we shouldn't do it here; the "validation above" might change in the future without someone meaning to make this panic, but we need to guard against future ourselves and emit an error here

So this is a direct copy/paste of what the other coprocessor layers are already doing, including subgraph.

Given this is meant to be as close to subgraph as possible, unless we're also refactoring the other stages (which I do not want to take ownership for in this PR), I'd prefer to go with being consistent with that the other stages are doing here.

(Though I will say in principle I agree 100% with not using unwrap! 😅)

aaronArinder · 2026-02-12T16:47:30Z

+            mapped_response: MappedResponse::Error {
+                error: runtime_error,
+                key: request.key,
+                problems: Vec::new(),


not totally sure I know what problems there would be in this case, but would problems ever lead to a break?

This is a connectors structure... problems are "mapping problems" with our connectors mapping language that get exposed to the mapping playground or the debugging panel on the embedded sandbox.

In this case, there is no mapping happening, so no problems to report!

aaronArinder · 2026-02-12T16:49:09Z

+        return Ok(ControlFlow::Break(res));
+    }
+
+    // Continue flow - apply modifications


what are the modifications? this section seemed a bit mysterious to me; it looks similar to how we do coprocessor/supergraph.rs, but with some extra flavor; might be nice to flesh out this comment to give the reader more direction in what to expect

aaronArinder · 2026-02-12T16:58:16Z

        // Tests for context key deletion functionality
    }
+
+    fn create_test_connector() -> Arc<Connector> {


can we put the connector tests in a mod block or something to make it more readable?

aaronArinder · 2026-02-12T17:11:38Z


    Ok(())
 }
+


might be good to have a test showing that a proper graphql error comes back to the client if the connectors coprocessor fails

aaronArinder

panic still scares me, but alas; lgtm!

pragl

Docs LGTM! I made a handful of suggestions for your consideration based on our style guide, but none of them are substantive, so I'm going ahead and approving.

Co-authored-by: Parker <parker.ragland@apollographql.com>

abernix

Post-merge: Can tick the checklist on the PR description?

Coprocessor hook for connectors request/response stages

142543c

This comment has been minimized.

Sign in to view

andrewmcgivery added 9 commits February 5, 2026 17:08

Fix build error

5322a58

Better handling of control-break errors

bb0ac04

Merge remote-tracking branch 'origin/dev' into am/connector_request_c…

175f3b1

…oprocessor

Small adjustments to code, proper context passing to response, proper…

d73c50a

… id passing to response, proper body modification in response

Merge remote-tracking branch 'origin/dev' into am/connector_request_c…

9d672b5

…oprocessor

Fix format error

c41a073

Add changeset

bf93c50

Update docs

cc5ee5d

Send JSON instead of string to request stage

ec010d6

BrynCooke reviewed Feb 10, 2026

View reviewed changes

aaronArinder reviewed Feb 12, 2026

View reviewed changes

andrewmcgivery added 7 commits February 12, 2026 09:48

Add comment about executed flag to process_connector_response_stage

3a42fe7

Add comment about executed flag to process_connector_request_stage

6f49706

Clarify apply modifications comment

4a32493

Move connector tests to a mod block

90f3693

Fix test imports

4d5ee4f

Add integration test for case where coprocessor fails

67a7536

Fix import order

e3f9032

andrewmcgivery marked this pull request as ready for review February 12, 2026 18:35

andrewmcgivery requested review from a team as code owners February 12, 2026 18:35

aaronArinder approved these changes Feb 12, 2026

View reviewed changes

Merge branch 'dev' into am/connector_request_coprocessor

dee3535

pragl approved these changes Feb 12, 2026

View reviewed changes

Comment thread docs/shared/coproc-typical-config.mdx Outdated

Comment thread docs/source/routing/customization/coprocessor/index.mdx Outdated

Comment thread docs/source/routing/customization/coprocessor/index.mdx Outdated

Apply suggestions from code review

87a2464

Co-authored-by: Parker <parker.ragland@apollographql.com>

andrewmcgivery merged commit faba864 into dev Feb 13, 2026
15 checks passed

andrewmcgivery deleted the am/connector_request_coprocessor branch February 13, 2026 02:44

abernix reviewed Feb 13, 2026

View reviewed changes

abernix mentioned this pull request Feb 24, 2026

prep release: v2.12.0 #8912

Merged

		impl Plugin for CoprocessorPlugin<HTTPClientService> {
		impl PluginPrivate for CoprocessorPlugin<HTTPClientService> {

		// unwrap is safe here because validate_coprocessor_output made sure control is available
		let control = co_processor_output.control.expect("validated above; qed");

		register_plugin!(
		register_private_plugin!(

Conversation

andrewmcgivery commented Feb 6, 2026 • edited by atlassian bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

apollo-librarian bot commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Docs preview ready

Uh oh!

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

smyrick commented Feb 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aaronArinder left a comment

Choose a reason for hiding this comment

Uh oh!

pragl left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

abernix left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

andrewmcgivery commented Feb 6, 2026 •

edited by atlassian bot

Loading

apollo-librarian bot commented Feb 6, 2026 •

edited

Loading