-
Notifications
You must be signed in to change notification settings - Fork 192
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
Conversation
return prevList; | ||
} else { | ||
return nonFavoriteConnections; | ||
return newNonFavoriteConnections; |
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 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.
💯 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. |
Did you consider splitting the shouldSave change from the new telemetry events? Seems to be quite loosely related. |
packages/compass-connection-import-export/src/hooks/use-import.ts
Outdated
Show resolved
Hide resolved
that's a valid concern. what needs to be cleaned up here is the |
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 |
c131dbf
to
acf4e0a
Compare
90d65bb
to
742ae71
Compare
that sounds great, should we update that ticket with a todo list too? |
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.
Looking good 👍 I left a small note but not a blocker.
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( |
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.
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.
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.
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?)
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.
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?
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.
yeah, that's probably a good guess. Though we probably thought you were doing this refactoring @gribnoysup :)
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.
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( |
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.
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({ |
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 other places that save info directly through saveConnectionInfo don't need to update 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.
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
note: separated the legacy parameter change, as I need it for the Save&Connect update #6034 |
@@ -360,7 +366,11 @@ export function useConnections({ | |||
Pick<ConnectionInfo, 'id'> |
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.
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?
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.
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
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.
actually we do pass partial in oidcUpdateSecrets
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.
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
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.
after merging your changes I updated the tracking so that it uses the updated connectionInfo, so this is now resolved 🎉
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.
Looks good, two small comments, nothing major
Description
Existing events
Connection Imported - when new connections are imported
added
New events
Connection Disconnected
Connection Created - when a new connection is saved
Connection Removed
** UPDATE ** Removed active_connection_count and inactive_connection_count upon further discussion. We might add these later if needed.
Checklist
Motivation and Context
Open Questions
Dependents
Types of changes