-
Notifications
You must be signed in to change notification settings - Fork 247
chore(intercom): Add request to the update server to determine if Intercom integration is allowed COMPASS-9371 #6982
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
Conversation
| return; | ||
| } | ||
|
|
||
| if (!(await isIntercomAllowed())) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: We shouldn't send a request networkTraffic is disabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We also want to prevent a request if the enableFeedbackPanel preference is false, or we're on web right? I'm guessing the web part is something we get from only accessing this from the compass electron side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
enableFeedbackPanel depens on network traffic already, so checking just one should be enough. We might want to just move this check higher in this method maybe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found a way to shuffle stuff around. I am checking networkTraffic explicitly to increase cohesion and avoid relying on an implicit fact (the enableFeedbackPanel depending on networkTraffic - as I could observe that, but personally failed to establish the reason for that as I was writing this).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd have a strong preference for us not to do that, deriveNetworkTrafficOptionState is a mechanism we specifically added so that feature flags for some features (like feedback panel) don't need to explicitly check for network traffic. I'm happy to discuss how to make it more visible if just looking at the preferences descriptions that use deriveNetworkTrafficOptionState is not enough, but introducing a different pattern just makes it more obscure. Looking at the code it's now not clear whether or not networkTraffic needs to be checked even if deriveNetworkTrafficOptionState is applied to the preference. If I look here, it needs to be, if I look at some other preferences it doesn't, and there's no explanation for why this is happening
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll rely on enableFeedbackPanel directly then 👍 I seached for deriveNetworkTrafficOptionState and I don't know why I wasn't able to find that before.
Another alternative would be for the DeriveValueFunction to be async and call the endpoint from there, as to completely disable the feature based on a response from the update server. But that might be more involved 🤔
28e787c to
938d4e3
Compare
|
I'm seeing some pretty consistent failures of the e2e tests related to dynamically changing the proxy preference, but I have no idea why 😬 I can reproduce it locally and it doesn't reproduce off |
|
Turns out the preflight request opened a connection which made the proxy tests fail when they requests afterwards. |
0f5f80d to
6ab3c4d
Compare
| // NOTE: we use 301 since intercom will redirects | ||
| // to the actual location of the widget script | ||
| fetchMock.resolves({ status: 301 } as Response); | ||
| fetchMock = sinon.stub(globalThis, 'fetch'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using this makes it possible to restore afterwards.
| // Used by proxy tests, since Chrome does not like proxying localhost | ||
| // (this does not result in actual outgoing HTTP requests) | ||
| extraAllowed.push('http://compass.mongodb.com/'); | ||
| extraAllowed.push('http://proxy-test-compass.mongodb.com/'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm changing this to avoid conflicts with the actual compass update server URL called when setting up intercom.
| await toggleEnableFeedbackPanel(shouldLoad); | ||
| } catch (error) { | ||
| debug('initial toggle failed', { | ||
| error: error instanceof Error && error.message, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just
| error: error instanceof Error && error.message, | |
| error |
?
| (error) => { | ||
| debug( | ||
| 'Failed to fetch intercom integration status, defaulting to false', | ||
| { error: error instanceof Error && error.message } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
| { error: error instanceof Error && error.message } | |
| { error } |
| ); | ||
| } | ||
|
|
||
| function isIntercomAllowed(allowNetworkTraffic = true): Promise<boolean> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I think we'd want to avoid the default argument here but we'll want to change this so we don't interact with allowNetworkTraffic here directly anyway, so it doesn't really matter)
cc710c2 to
6441053
Compare
gribnoysup
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have one note / nit comment, but otherwise looks good!
|
|
||
| toggleEnableFeedbackPanel(!!enableFeedbackPanel); | ||
| try { | ||
| await toggleEnableFeedbackPanel(shouldLoad); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't have a good suggestion from the top of my head, but I did find it a bit mind bending that shouldLoad here already takes awaited isIntercomAllowed into account, but then toggleEnableFeedbackPanel immediately fetches it again. I understand the purpose of this, but kinda wish this was maybe somehow less tangled. I don't think it's that big of a deal, but wanted to highlight
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a valid concern and I had the response cached in a previous commit. I reverted it because it felt a bit premature, but thinking more about it, I do think it makes sense - this is going to be fetched by every render process and we might as well do it once instead of twice.
6441053 to
1e07960
Compare
Description
Combined with https://github.com/10gen/compass-mongodb-com/pull/133, merging this will introduce a preflight request to the update server to determine if Compass is allowed to setup the Intercom integration.
TODO: We might want to send the Compass version and OS / arch to that endpoint, in order to be able to selectively respond based on those parameters. But is that a thing that we will reasonably be using?
Checklist
Motivation and Context
Open Questions
Dependents
Types of changes