Skip to content

refactor: add ability to restore context #111

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

Merged
merged 1 commit into from
Sep 23, 2022
Merged

Conversation

aaron-steinfeld
Copy link
Contributor

Description

Added the ability to restore the graphql request context from the grpc context. This is required for grpc instrumentation and interceptors which do not give direct access to the graphql context.

Testing

Updated unit tests

Checklist:

  • My changes generate no new warnings
  • I have added tests that prove my fix is effective or that my feature works
  • Any dependent changes have been merged and published in downstream modules

@aaron-steinfeld aaron-steinfeld requested a review from a team as a code owner September 23, 2022 15:57
@github-actions
Copy link

Test Results

98 tests  +1   98 ✔️ +1   33s ⏱️ +5s
32 suites ±0     0 💤 ±0 
32 files   ±0     0 ±0 

Results for commit dc864a7. ± Comparison against base commit 3584f91.

@codecov
Copy link

codecov bot commented Sep 23, 2022

Codecov Report

Merging #111 (dc864a7) into main (7b93309) will decrease coverage by 0.01%.
The diff coverage is 54.54%.

@@             Coverage Diff              @@
##               main     #111      +/-   ##
============================================
- Coverage     58.37%   58.35%   -0.02%     
- Complexity      255      256       +1     
============================================
  Files            87       87              
  Lines          1314     1323       +9     
  Branches         39       39              
============================================
+ Hits            767      772       +5     
- Misses          517      521       +4     
  Partials         30       30              
Flag Coverage Δ
unit 58.35% <54.54%> (-0.02%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...e/graphql/attributes/AttributeModelTranslator.java 65.85% <0.00%> (-1.65%) ⬇️
...ommon/schema/attributes/MetricAggregationType.java 0.00% <0.00%> (ø)
.../AttributeModelMetricAggregationTypeConverter.java 0.00% <0.00%> (ø)
...ils/attributes/MetricAggregationTypeConverter.java 0.00% <0.00%> (ø)
...ttributes/AttributeModelMetricAggregationType.java 100.00% <100.00%> (ø)
...graphql/utils/grpc/PlatformGrpcContextBuilder.java 96.29% <100.00%> (+0.64%) ⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@@ -16,8 +19,12 @@

class PlatformGrpcContextBuilder implements GrpcContextBuilder {

private final Cache<String, GraphQlRequestContext> contextCache =
CacheBuilder.newBuilder().expireAfterAccess(Duration.ofMinutes(1)).maximumSize(1000).build();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I used a small short lived cache to do this as the actual transformation to grpc context is lossy - it's not possible to recreate the initial context directly, and the period of time we need to be able to restore a context is typically very small (the time it takes to build the request to the time it takes to make the request).

Copy link
Contributor

Choose a reason for hiding this comment

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

Any chance the max size will be hit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I guess it could (this would be > 1000 requests per minute), but that's not actually an issue since guava caches are LRU and it'll just help us evict entries quicker (we only need them for a short order of time, typically on the order of millis). The issue would be if we have to handle more than the cache size (1000) concurrently which is far beyond the current scale. If it makes you feel better I can make it configurable :)

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok. So it's rare a cache item stays in there for more than a couple of milliseconds?

Copy link
Contributor Author

@aaron-steinfeld aaron-steinfeld Sep 23, 2022

Choose a reason for hiding this comment

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

It's rare that we need it to, but the only mechanisms that remove it currently are the size and time expirations.

The expected flow is that when making a remote request in a DAO class, an impl will trade their GQL context for a GRPC context. The GRPC context is used to make the request. The need for this class is for any hooks at the GRPC level - if we're instrumenting or intercepting the calls, we can get the GRPC context that was used to make them, but we can't (without this PR) get the GQL context that was used to create that GRPC context. If we want to make other calls into GQL code in those interceptor classes, we need that GQL context back (so the expected elapsed time here is from initiating to intercepting a client request - at least for my use case)

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.

2 participants