fix: identifyRequest intake when persistent data exists

[deammer]

Summary

This fixes an issue with identifying users in certain contexts, namely across subdomains. See this comment for more information.

Resolves #1010.

Testing Plan

• Was this tested locally? ➡️ It was tested successfully on real live traffic.

The testing scenario:

1. customer lands on www.website.com
   a. mParticle initializes on the subdomain
   b. mParticle starts a session and stores it in local storage
2. customer is sent to login.website.com to log in
   a. mParticle initializes on the subdomain
   b. mParticle starts a session and stores it in local storage
3. customer logs in
   a. mParticle.login() is called
   b. a cookie containing the customerid is stored
   c. user is thus identified on login.website.com
4. customer is sent back to www.website.com
   a. mParticle initializes on the subdomain
   b. mParticle does not start a new session because there's already one in local storage

Before this fix: users would not be identified.

With this fix: users are consistently identified.

[deammer]

@alexs-mparticle tagging you here as requested!

[alexs-mparticle]

This PR is a great start. Thanks for opening it. My main request is for you to write some tests around the new feature to make sure any dependent functionality isn't affected.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[deammer]

Hey @alexs-mparticle thank you for the review 🙏 I've made the changes you requested except for writing tests, which looks pretty involved based on a brief look I took. Is there any chance you or your team could take care of that?

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[alexs-mparticle]

Hi @deammer — apologies for the long delay on this. Thank you for identifying and validating the fix.

Since this PR was opened, the area was refactored in #1046, which replaced the persistence.cu check with a more general hasIdentityRequestChanged() utility that should cover the scenario described in #1010. That change includes full test coverage as well.

I'm going to close this out since it hasn't been merged and the underlying issue appears to be addressed, but if you're still seeing the problem on a recent version, let us know and we can reopen.

Thanks again for the contribution!