Skip to content

Conversation

@samgst-amazon
Copy link
Contributor

@samgst-amazon samgst-amazon commented Oct 7, 2024

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)

Description

Changed the emitUserState function to add authScopes to the telemetry record. Scopes were previously not recorded with this metric.

Checklist

  • My code follows the code style of this project
  • I have added tests to cover my changes
  • A short description of the change has been added to the CHANGELOG if the change is customer-facing in the IDE.
  • I have added metrics for my changes (if required)

License

I confirm that my contribution is made under the terms of the Apache 2.0 license.

@github-actions
Copy link

github-actions bot commented Oct 7, 2024

Qodana Community for JVM

4 new problems were found

Inspection name Severity Problems
Unused import directive 🔶 Warning 2
Usage of redundant or deprecated syntax or deprecated symbols 🔶 Warning 1
Variable declaration could be moved inside 'when' ◽️ Notice 1

💡 Qodana analysis was run in the pull request mode: only the changed files were checked
☁️ View the detailed Qodana report

Contact Qodana team

Contact us at [email protected]

@samgst-amazon samgst-amazon changed the title Telemetry: emit auth scopes in user state Update telemetry: emit auth scopes in user state Oct 7, 2024
@samgst-amazon
Copy link
Contributor Author

The userState() function in AuthTelemetry did not have a parameter for authScopes-- hence just calling the TelemetryService function directly to add that datum in place. That's how VSCode was doing it

@samgst-amazon samgst-amazon marked this pull request as ready for review October 7, 2024 22:20
@samgst-amazon samgst-amazon requested a review from a team as a code owner October 7, 2024 22:20
Comment on lines 247 to 249
createTime(Instant.now())
unit(Unit.NONE)
value(1.0)
Copy link
Contributor

Choose a reason for hiding this comment

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

these are implicit

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They are implicit if you use the userState function in AuthTelemetry-- which just calls the TelemetryService function using these values. I thought I had to add them here since I was not using the userState function and they weren't being set. I did not see a method signature in AuthTelemetry that would let me pass in the extra authScopes datum-- and I wasn't sure where/if I could update the userState method.

Copy link
Contributor

Choose a reason for hiding this comment

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

This metric is currently in telemetryOverride. We need to use the one from common.

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 understand that our AuthTelemetry is being generated. no version of AuthTelemetry.userState() accepts authScopes as a parameter. I think this might be why? :

https://github.com/aws/aws-toolkit-common/blob/49de773b65efdeaadea5c30859cf286ccd74ec5b/telemetry/definitions/commonDefinitions.json#L2708C1-L2710C19

I'll try making some changes to common locally to see if I can generate a version of the function that does.

Comment on lines 237 to 243
val scopes = ToolkitAuthManager.getInstance().listConnections().flatMap { connection ->
when (connection) {
is ProfileSsoManagedBearerSsoConnection -> connection.scopes
is LegacyManagedBearerSsoConnection -> connection.scopes
else -> emptyList()
}
}.toSet()
Copy link
Contributor

Choose a reason for hiding this comment

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

honestly it seems odd that we inspect every connection instead of what the extension is actively using, which seems more useful

Copy link
Contributor Author

Choose a reason for hiding this comment

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

VScode seems to be doing this same thing: grabbing the scopes from every SSO connection returned from listConnections so that's why I did it this way.

https://github.com/aws/aws-toolkit-vscode/blob/de9d7cfcd8930079bc4d9e105323ab64cf843302/packages/core/src/extension.ts#L288

authStatus = getAuthStatus(project),
passive = true
)
val explorerConnection = ToolkitConnectionManager.getInstance(project).activeConnection()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right now, I am just grabbing the connection being used by the explorer. I see that the activeConnection() function is marked as deprecated, but there is no alternative for getting the explorer connection from what I've seen. The getActiveConnectionForFeature function seems to work only for Q, CodeCatalyst, and CodeWhisperer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If we want to look at all the active connections, I think it would be easy enough to use a function like:


to get the scopes from each active connection. If we are looking at enabled connections in this Telemetry metric, why not the scopes for those enabled connections?

@github-actions
Copy link

github-actions bot commented Oct 16, 2024

Qodana Community for JVM

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked
☁️ View the detailed Qodana report

Contact Qodana team

Contact us at [email protected]

Comment on lines 247 to 249
createTime(Instant.now())
unit(Unit.NONE)
value(1.0)
Copy link
Contributor

Choose a reason for hiding this comment

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

This metric is currently in telemetryOverride. We need to use the one from common.

val codeCatalystConnection = checkBearerConnectionValidity(project, BearerTokenFeatureSet.CODECATALYST)
addScopes(codeCatalystConnection)

val codeWhispererConnection = checkBearerConnectionValidity(project, BearerTokenFeatureSet.CODEWHISPERER)
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if we still need this since Q or we should just record Q

Copy link
Contributor Author

Choose a reason for hiding this comment

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

From Dhruvi: " let's not be concerned about old customers since most of them have migrated"

I'll remove it.

}
}

val explorerConnection = checkIamConnectionValidity(project)
Copy link
Contributor

Choose a reason for hiding this comment

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

We could also probably check the connection type and use the addScopes function only if the connection type is IDC. We can probably just hardcode it anyway

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Check the connection type of the explorer only? Would that not ignore the other connections/scopes available if those other features are using the IdC connection type while the explorer isnt?

This comment was marked as outdated.

ActiveConnection.ValidIam(connectionType = connectionType, activeConnectionIam = currConn)
}
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Wrote this because the other function was using isCredentialSSO would always return IAM, even in cases where it should be IAM_IDC.

Copy link
Contributor

Choose a reason for hiding this comment

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

The other function is for the getting started auth which contains a dialog that accepts a session name.
Where does this function determine the credential type?

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 saw that there was a CredentialType enum attached to the selected credentials so I thought I could use that. If the credentialType is an SsoProfile, does that not mean it is part of an IDC session?

fun getEnabledConnections(project: Project?): String =
getEnabledConnectionsForTelemetry(project).joinToString(",")

fun getAuthScopesForTelemetry(project: Project?): Set<String> {
Copy link
Contributor

Choose a reason for hiding this comment

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

The function above repeats some of the logic used here, can we move the common logic to a function?

ActiveConnection.ValidIam(connectionType = connectionType, activeConnectionIam = currConn)
}
}

Copy link
Contributor

Choose a reason for hiding this comment

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

The other function is for the getting started auth which contains a dialog that accepts a session name.
Where does this function determine the credential type?

@samgst-amazon samgst-amazon merged commit 82f2275 into main Nov 7, 2024
16 of 17 checks passed
@samgst-amazon samgst-amazon deleted the samgst/emitAuthScopesInUserState branch November 7, 2024 21:14
dhasani23 pushed a commit to ntarakad-aws/aws-toolkit-jetbrains that referenced this pull request Nov 18, 2024
* add authScopes to emitUserState telemetry

* add authScopes to emitUserState telemetry

* Replace userState function with direct TelemetryService record function to capture authScopes

* add value parameter

* fix whitespace

* Update plugins/core/jetbrains-community/src/software/aws/toolkits/jetbrains/core/gettingstarted/GettingStartedAuthUtils.kt

Co-authored-by: Richard Li <[email protected]>

* Check current explorerConnection for scopes only

* Add function to grab scopes from each activeConnection used that is connected/expired.

* remove TelemetryOverride definition and use common's telemetry function instead

* remove unused imports

* Change the way explorer connection scope is checked

* remove check for CodeWhispererConnection: merged into qConnection & qScopes

* add common logic to one function

* Update telemetryOverride.json

missed {

---------

Co-authored-by: Richard Li <[email protected]>
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.

3 participants