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

Enhanced signature generation #5153

Open
wants to merge 28 commits into
base: dev
Choose a base branch
from
Open

Enhanced signature generation #5153

wants to merge 28 commits into from

Conversation

BrynCooke
Copy link
Contributor

@BrynCooke BrynCooke commented May 13, 2024

Adds a new experimental configuration to support enhanced signature generation. The changes are:

Remove some hacks and quirks of the JS implementation related to properly sorting everything and using commas vs spaces
Includes aliases in the signature
Includes the full normalized form of input objects
Fixes ROUTER-262
Replaces PR #5062

To get this over the line the tests need a little refactoring to use insta and maybe Asset to allow easy addition of new tests.


Checklist

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

  • Changes are compatible1
  • Documentation2 completed
  • Performance impact assessed and acceptable
  • Tests added and passing3
    • Unit Tests
    • Integration Tests
    • Manual Tests

Exceptions

Note any exceptions here

Notes

Footnotes

  1. 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.

  2. Configuration is an important part of many changes. Where applicable please try to document configuration examples.

  3. Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions.

@router-perf
Copy link

router-perf bot commented May 13, 2024

CI performance tests

  • step - Basic stress test that steps up the number of users over time
  • 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
  • large-request - Stress test with a 1 MB request payload
  • events - Stress test for events with a lot of users and deduplication ENABLED
  • xxlarge-request - Stress test with 100 MB request payload
  • events_without_dedup - Stress test for events with a lot of users and deduplication DISABLED
  • xlarge-request - Stress test with 10 MB request payload
  • step-jemalloc-tuning - Clone of the basic stress test for jemalloc tuning
  • events_callback - Stress test for events with a lot of users and deduplication ENABLED in callback mode
  • no-graphos - Basic stress test, no GraphOS.
  • reload - Reload test over a long period of time at a constant rate of users
  • 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_without_dedup_callback - Stress test for events with a lot of users and deduplication DISABLED using callback mode
  • const - Basic stress test that runs with a constant number of users

@BrynCooke BrynCooke requested review from bnjjj and Geal May 14, 2024 13:48
@@ -356,33 +404,60 @@ fn format_selection_set(selection_set: &SelectionSet, f: &mut fmt::Formatter) ->
}

if !fields.is_empty() || !named_fragments.is_empty() || !inline_fragments.is_empty() {
fields.sort_by(|&a, &b| a.name.cmp(&b.name));
if is_enhanced(normalization_algorithm) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't we just call it once for everywhere in the code instead of recalling this function everytime ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'd have to pass around a boolean instead of the enum if we only wanted to call this once, and I figured it would be better to pass around the enum instead in case we add a new algorithm in the future. I'll change it to a macro though which should fix any performance concerns.

Comment on lines +633 to +641
f.write_str("{")?;
for (index, (name, val)) in o.iter().enumerate() {
if index != 0 {
f.write_str(",")?;
}
write!(f, "{}:", name)?;
format_value(val, normalization_algorithm, f)?;
}
f.write_str("}")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we basically trying to serialize it in json here ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's similar but with enough special cases to justify not using a JSON serializer (IMO). We need to strip the string and int values and the array contents, and also the keys are not surrounded in quotes.

// We need to use this because of the import method that the fuzzer uses. The fuzzer can't have apollo-router as
// a direct dependency because that means the build crashes, so we use a dev dependency and do a path hack. This
// means that the fuzzer can't import from the Configuration namespace and has to import this instead.
#[allow(dead_code)]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to remove ?

Copy link
Contributor

@bonnici bonnici May 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When I remove it I get the error variant ``Enhanced`` is never constructed even though it's obviously used below. I'm not sure if there's a better way to get around this rather than having the #[allow(dead_code)]?

#[derive(Clone, PartialEq, Eq, Default, Derivative, Serialize, Deserialize, JsonSchema)]
#[derivative(Debug)]
#[serde(rename_all = "lowercase")]
pub(crate) enum ApolloSignatureNormalizationAlgorithm {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have a duplicate enum here and in the studio_interop module ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was a consequence of the way we had to do the weird import of the module in the fuzz test:

#[path = "../../apollo-router/src/apollo_studio_interop/mod.rs"]
mod apollo_router_usage_reporting;
use apollo_router_usage_reporting::generate_usage_reporting;
use apollo_router_usage_reporting::SignatureNormalizationAlgorithm;
use apollo_router_usage_reporting::UsageReportingComparisonResult;

Because of that I was unable to use the enum defined in the configuration module in the interop module. I had a DM conversation with Jeremy and Simon and the separate enums was the best workaround we could think of.

There's another thread on why we needed to do the import that way somewhere and I try to can find it if you're interested but the end result was that we just had to do it that way.

Comment on lines +627 to +635
if self.experimental_apollo_signature_normalization_algorithm
== ApolloSignatureNormalizationAlgorithm::Enhanced
&& self.experimental_apollo_metrics_generation_mode != ApolloMetricsGenerationMode::New
{
return Err(ConfigurationError::InvalidConfiguration {
message: "`experimental_apollo_signature_normalization_algorithm: enhanced` requires `experimental_apollo_metrics_generation_mode: new`",
error: "either change to the legacy signature normalization mode, or change to new metrics generation".into()
});
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a test covering this rule because once we will update the configuration field without the experimental support we will also want to update this error message

Comment on lines +606 to +616
let signature_normalization_mode = match self
.configuration
.experimental_apollo_signature_normalization_algorithm
{
ApolloSignatureNormalizationAlgorithm::Legacy => {
SignatureNormalizationAlgorithm::Legacy
}
ApolloSignatureNormalizationAlgorithm::Enhanced => {
SignatureNormalizationAlgorithm::Enhanced
}
};
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we still have to duplicate this enum maybe a From impl would be better

@bonnici
Copy link
Contributor

bonnici commented May 30, 2024

I've addressed the PR comments but I don't have access to push to this branch/PR. I made a new branch/PR but it's based on the latest dev code so there are some unrelated changes in the PR. If this branch is synced with dev I think the PR should look a lot cleaner.

#5285

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants