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

feat: new telemetry events for connections #6018

Merged
merged 26 commits into from
Jul 31, 2024
Merged

feat: new telemetry events for connections #6018

merged 26 commits into from
Jul 31, 2024

Conversation

paula-stacho
Copy link
Contributor

@paula-stacho paula-stacho commented Jul 11, 2024

Description

Existing events

Connection Imported - when new connections are imported
added

  • connection_ids

New events

Connection Disconnected

  • connection_id

Connection Created - when a new connection is saved

  • connection_id
  • color (optional)

Connection Removed

  • connection_id

** UPDATE ** Removed active_connection_count and inactive_connection_count upon further discussion. We might add these later if needed.

Checklist

Motivation and Context

  • Bugfix
  • New feature
  • Dependency update
  • Misc

Open Questions

Dependents

Types of changes

  • Backport Needed
  • Patch (non-breaking change which fixes an issue)
  • Minor (non-breaking change which adds functionality)
  • Major (fix or feature that would cause existing functionality to change)

@github-actions github-actions bot added the feat label Jul 11, 2024
return prevList;
} else {
return nonFavoriteConnections;
return newNonFavoriteConnections;
Copy link
Contributor Author

@paula-stacho paula-stacho Jul 11, 2024

Choose a reason for hiding this comment

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

it's not visible in the diff, but there are higher scope consts with the name favoriteConnections and nonFavoriteConnections. I noticed while exploring some other options for triggering the events.

@paula-stacho paula-stacho added the no release notes Fix or feature not for release notes label Jul 11, 2024
@mcasimir
Copy link
Collaborator

mcasimir commented Jul 12, 2024

it also make sense to save before and not after connecting

💯

The reason for this was to keep track of the history. Can we create a follow up ticket to clean this up? I'm not sure folks removing the FF will be aware of it.

@mcasimir
Copy link
Collaborator

Did you consider splitting the shouldSave change from the new telemetry events? Seems to be quite loosely related.

@paula-stacho
Copy link
Contributor Author

it also make sense to save before and not after connecting

💯

The reason for this was to keep track of the history. Can we create a follow up ticket to clean this up? I'm not sure folks removing the FF will be aware of it.

that's a valid concern. what needs to be cleaned up here is the legacyShouldSaveConnection, I changed the name to mark it for the cleanup. we do have a general cleanup ticket https://jira.mongodb.org/browse/COMPASS-7906, but I do wonder if we're doing good enough job of marking everything 🙈 I can add a todo with a link to that ticket.

@paula-stacho
Copy link
Contributor Author

Did you consider splitting the shouldSave change from the new telemetry events? Seems to be quite loosely related.

I encountered several issues, one with the duplication and another with saving twice. the first was a problem on it's own so it got a ticket. this one was just unnecessary, it only became problem for the tracking (due to the asynchronous nature of repository updates we couldn't reliably tell that the connection already exists when it was saved second time). still, I can make it a separate ticket if that makes it easier to review

@paula-stacho paula-stacho marked this pull request as ready for review July 15, 2024 09:31
@mcasimir
Copy link
Collaborator

add a todo with a link to that ticket

that sounds great, should we update that ticket with a todo list too?

Copy link
Contributor

@himanshusinghs himanshusinghs left a comment

Choose a reason for hiding this comment

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

Looking good 👍 I left a small note but not a blocker.

packages/compass-connections/src/connections-manager.ts Outdated Show resolved Hide resolved
@paula-stacho
Copy link
Contributor Author

add a todo with a link to that ticket

that sounds great, should we update that ticket with a todo list too?

making a complete list is not going to be that simple at this point, and rather than making an incomplete list I'd leave it for when the ticket is picked up.

connectionInfo: ConnectionInfo | undefined,
activeAndInactiveConnectionsCount: { active: number; inactive: number }
) => {
trackConnectionRemovedEvent(
Copy link
Collaborator

@mcasimir mcasimir Jul 15, 2024

Choose a reason for hiding this comment

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

Similar to my previous comment. I'm curious about what prompted this "callback" / "event-driven" style here.

It seems onDisconnected, onConnectionCreated, and onConnectionRemoved exclusively call the respective track functions and require adapting the calling point to surface additional information.

What is the benefit of this approach? From my perspective, this indirection might be obscuring the code's intention, making it harder to follow. I'm open to discuss this further of course, but i don't see much of an advantage to be doing this instead of just calling trackConnection[X]Event directly.

Copy link
Collaborator

Choose a reason for hiding this comment

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

FWIW the only reason for that is that tracking requires desktop-only dependencies so had to stay away from the code shared with web, my proposal was to only pass the extra tracking info somehow to compass-connections instead of exposing the hook, but this was not done right away and instead we had a refactor ticket (that I can't really find anymore, I guess it was not linked here and maybe closed?)

Copy link
Collaborator

@gribnoysup gribnoysup Jul 15, 2024

Choose a reason for hiding this comment

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

Found it: we initially had https://jira.mongodb.org/browse/COMPASS-7740 opened for this, but it's assigned to me and closed. I don't really remember why it got resolved like that, but I'm guessing we decided that it will be just resolved with some other refactoring that still needs to happen?

Copy link
Collaborator

Choose a reason for hiding this comment

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

yeah, that's probably a good guess. Though we probably thought you were doing this refactoring @gribnoysup :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

desktop-only dependencies so had to stay away from the code shared with web

Isn't that addressed by providing a different implementation of services?

connectionInfo: ConnectionInfo | undefined,
activeAndInactiveConnectionsCount: { active: number; inactive: number }
) => {
trackConnectionRemovedEvent(
Copy link
Collaborator

Choose a reason for hiding this comment

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

FWIW the only reason for that is that tracking requires desktop-only dependencies so had to stay away from the code shared with web, my proposal was to only pass the extra tracking info somehow to compass-connections instead of exposing the hook, but this was not done right away and instead we had a refactor ticket (that I can't really find anymore, I guess it was not linked here and maybe closed?)


if (activeConnectionId === connectionInfo.id) {
// Update the active connection if it's currently selected.
dispatch({
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why other places that save info directly through saveConnectionInfo don't need to update this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good question. I actually only moved this function and I haven't questioned this bit. I'd say this is a legacy thing, because in multiple connections the activeConnection is only used by the connection form, and the form is closed when we save. perhaps @himanshusinghs can confirm? if I'm right we could mark this for a cleanup

@paula-stacho paula-stacho added the blocked Waiting for something before merging/reviewing further label Jul 16, 2024
@paula-stacho
Copy link
Contributor Author

note: separated the legacy parameter change, as I need it for the Save&Connect update #6034

@paula-stacho paula-stacho added wip and removed blocked Waiting for something before merging/reviewing further labels Jul 18, 2024
@paula-stacho paula-stacho removed the wip label Jul 29, 2024
@@ -360,7 +366,11 @@ export function useConnections({
Pick<ConnectionInfo, 'id'>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Not related to your changes, but I just noticed that I missed changing this type to PartialConnectionInfo that I added in the refactor, do you mind adjusting as a drive-by?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Also looking closer at this, I'm pretty sure we never actually pass the partial here, so maybe this special case type is not even needed. I copied this from previous implementation without digging too deep

Copy link
Contributor Author

Choose a reason for hiding this comment

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

actually we do pass partial in oidcUpdateSecrets

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ahhh, true, missed that! Hmmm, that method is internal to this hook logic though and we do have the whole connection info object passed to it so we probably can do the merge there ourselves? Totally no strong preference though, mostly saying this because I saw your discussion above about this whole partial / full info type and maybe if we want to remove the ambiguity, we can just refactor away the use-case for this partial type

Copy link
Contributor Author

@paula-stacho paula-stacho Jul 31, 2024

Choose a reason for hiding this comment

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

after merging your changes I updated the tracking so that it uses the updated connectionInfo, so this is now resolved 🎉

packages/compass/src/app/utils/telemetry.ts Outdated Show resolved Hide resolved
Copy link
Collaborator

@gribnoysup gribnoysup left a comment

Choose a reason for hiding this comment

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

Looks good, two small comments, nothing major

@paula-stacho paula-stacho merged commit ada8b30 into main Jul 31, 2024
28 checks passed
@paula-stacho paula-stacho deleted the COMPASS-7724-3 branch July 31, 2024 11:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat no release notes Fix or feature not for release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants