fix(federation): fixed sibling typename optimization handling multiple __typename selections

[duckki]

Problem

The sibling typename optimization treated __typename and __typename @Skip(if:$X) interchangeably. Thus, one could become a sibling of the other, depending on the order they appear in query. That is problematic, since sibling typename should not have directives or aliases.

The same issue found in JS QP. The matching PR for that is apollographql/federation#3164.

Rust QP didn't have the other problem dropping some __typename selections in fetch operations like JS QP. But, still ordering could be wrong, picking __typename with directives ahead of the plain __typename.

Fix Summary

• updated to only fold a plain __typename without alias/directives.
• also, fixed __typename ordering in fetch operations to put the plain __typename ahead of others.

---

Checklist

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

• Changes are compatible[^1]
• Documentation[^2] completed
• Performance impact assessed and acceptable
• Tests added and passing[^3]
  • Unit Tests
  • Integration Tests
  • Manual Tests

[svc-apollo-docs]

✅ Docs Preview Ready

No new or changed pages found.

[github-actions]

@duckki, please consider creating a changeset entry in /.changesets/. These instructions describe the process and tooling.

[router-perf]

CI performance tests

• connectors-const - Connectors stress test that runs with a constant number of users
• const - Basic stress test that runs with a constant number of users
• demand-control-instrumented - A copy of the step test, but with demand control monitoring and metrics enabled
• demand-control-uninstrumented - A copy of the step test, but with demand control monitoring enabled
• enhanced-signature - Enhanced signature enabled
• events - Stress test for events with a lot of users and deduplication ENABLED
• events_big_cap_high_rate - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity
• events_big_cap_high_rate_callback - Stress test for events with a lot of users, deduplication enabled and high rate event with a big queue capacity using callback mode
• events_callback - Stress test for events with a lot of users and deduplication ENABLED in callback mode
• events_without_dedup - Stress test for events with a lot of users and deduplication DISABLED
• events_without_dedup_callback - Stress test for events with a lot of users and deduplication DISABLED using callback mode
• extended-reference-mode - Extended reference mode enabled
• large-request - Stress test with a 1 MB request payload
• no-tracing - Basic stress test, no tracing
• reload - Reload test over a long period of time at a constant rate of users
• step-jemalloc-tuning - Clone of the basic stress test for jemalloc tuning
• step-local-metrics - Field stats that are generated from the router rather than FTV1
• step-with-prometheus - A copy of the step test with the Prometheus metrics exporter enabled
• step - Basic stress test that steps up the number of users over time
• xlarge-request - Stress test with 10 MB request payload
• xxlarge-request - Stress test with 100 MB request payload

[goto-bus-stop]

This LGTM!

e; filed a ticket for the below.

---

I think we should audit all our __typename checks soon to see if we are doing the right thing, IIRC there are several places where we just == TYPENAME_FIELD, sometimes checking for directives and sometimes not. I'd also like to know if we do the right thing when there are multiple typename selections with different aliases, and other edge cases

[duckki]

This LGTM!

e; filed a ticket for the below.

I think we should audit all our __typename checks soon to see if we are doing the right thing, IIRC there are several places where we just == TYPENAME_FIELD, sometimes checking for directives and sometimes not. I'd also like to know if we do the right thing when there are multiple typename selections with different aliases, and other edge cases

I've casually looked around and didn't find any other places that need to be fixed. But, it wasn't exhaustive.