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

Remove the unnecessary code line because of fix in common #2135

Open
wants to merge 27 commits into
base: dev
Choose a base branch
from

Conversation

Yuki-YuXin
Copy link
Contributor

@Yuki-YuXin Yuki-YuXin commented Jul 1, 2024

Company PR: AzureAD/microsoft-authentication-library-common-for-android#2435

  1. Remove the conditional setting of the correlation ID in AccountState since it's a quick fix to pass the tests.
  2. Add try catch block for the UUID to String

@github-actions github-actions bot added the msal label Jul 1, 2024
@@ -30,7 +30,7 @@ resources:
- repository: common
type: github
name: AzureAD/microsoft-authentication-library-common-for-android
ref: dev
ref: robert/empty-correlation-id-fixes
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Revert it back before the merge.

Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we have this here?

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 cannot change the targe branch in the DevOps portal thus change the command here.

// Set it to a default value.
.correlationId(DiagnosticContext.INSTANCE.getThreadCorrelationId())
// If default value "UNSET", generate a new UUID as correlationId.
.correlationId(Objects.equals(DiagnosticContext.INSTANCE.getThreadCorrelationId(), "UNSET") ? UUID.randomUUID().toString() : DiagnosticContext.INSTANCE.getThreadCorrelationId())
Copy link
Contributor

Choose a reason for hiding this comment

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

This logic doesn't belong here. it's the responsibility of DiagnosticContext to generate an ID, and do additional null checks to ensure an actual ID is returned.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Update the logic inside DiagnosticContext getThreadCorrelationId()

@@ -262,7 +262,7 @@ class NativeAuthPublicClientApplication(
GetAccountResult.AccountFound(
resultValue = AccountState.createFromAccountResult(
account = account,
correlationId = DiagnosticContext.INSTANCE.threadCorrelationId,
correlationId = "",
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you check what MSAL does here?

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, what was your thinking behind changing this from the thread ID to an empty string?

Copy link
Contributor Author

@Yuki-YuXin Yuki-YuXin Jul 19, 2024

Choose a reason for hiding this comment

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

This path generate AccountState from the SDK cache (authClient.getCurrentAccount())

The default value of DiagnosticContext.INSTANCE.threadCorrelationId is UNSET. And currently, SDK won't transform “UNSET" into UUID.

If use DiagnosticContext.INSTANCE.threadCorrelationId,

  1. authClient.getCurrentAccount() before signIn. correlation id would be "UNSET"
  2. signIn. correlation id should be UUID
  3. authClient.getCurrentAccount() after signIn. When getting correlation id again then becomes UUID as the sign in flow.

I am not sure if the difference between the two correlation ids before and after is what we want

@@ -341,7 +341,7 @@ class NativeAuthPublicClientApplication(
return@withContext SignInError(
errorType = ErrorTypes.INVALID_USERNAME,
errorMessage = "Empty or blank username",
correlationId = "UNSET"
correlationId = ""
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not set it at all, meaning the value will be null?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The correlationId parameter is mandatory. Setting it to “” would be much easier than dealing with if null.

@@ -77,7 +77,7 @@ class AccountState private constructor(

constructor (parcel: Parcel) : this (
account = parcel.serializable<IAccount>() as IAccount,
correlationId = parcel.readString() ?: "UNSET",
correlationId = parcel.readString() ?: "",
Copy link
Contributor

Choose a reason for hiding this comment

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

Doesn't UUID.fromString("") also produce an exception?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a good point. How about generating random UUID here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Keep the original "UNSET" string.

@@ -309,12 +309,17 @@ class AccountState private constructor(
correlationId = correlationId
)

val privateCorrelationId = if (correlationId == "UNSET") { UUID.randomUUID().toString() } else { correlationId }
try {
UUID.fromString(correlationId)
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: maybe assign the result to a variable and use it in the builder to avoid calling the fromString() method twice

Copy link
Contributor

Choose a reason for hiding this comment

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

@Yuki-YuXin let's run the tests without this fix here to ensure it works not. But let's keep this fix here as well, to avoid any production crashes (but clean it up a bit, e.g. call DiagnosticContext.INSTANCE.getThreadCorrelationId() so that a new UUID is generated in there, rather than here at the call site).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Local GetAccessTokenTests passed with and without the changes here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants