feat: add error and warning codes for identity and roktManager

[jaissica12]

Background

• Error and warning logs across roktManager, identity, and identityApiClient were only outputting to the browser console via Logger, with no remote visibility in monitoring tools.
• ReportingLogger was already wired to Logger.error() so started error/warning logging for monitoring

What Has Changed

• Wired up ReportingLogger across roktManager.ts, identity.js, and identityApiClient.ts by adding specific ErrorCodes to all error and warning logs.
• Extended Logger.warning() to accept an optional ErrorCodes parameter and forward to ReportingLogger, matching the existing Logger.error() pattern.
• 13 new ErrorCodes added to logging/types.ts for granular remote reporting:
  • ROKT_IDENTITY_MISMATCH — email/hash mismatch during selectPlacements
  • ROKT_HASHING_FAILED — SHA-256 hashing failures
  • ROKT_PLACEMENT_MAPPING_FAILED — config parsing errors
  • ROKT_IDENTITY_FALLBACK_FAILED — onReadyCallback failure
  • ROKT_QUEUE_PROCESSING_FAILED — message queue processing errors
  • ROKT_SELECT_PLACEMENTS_FAILED — selectPlacements catch-all failure
  • ROKT_SET_EXTENSION_DATA_FAILED — extension data setting failure
  • ROKT_USE_EXTENSION_FAILED — extension usage failure
  • USER_ATTRIBUTE_ERROR — invalid key/value in user attribute methods
  • IDENTITY_REQUEST — identity validation, alias, and server response errors
  • DEPRECATED_METHOD — deprecated cart/onUserAlias method usage tracking
  • AUDIENCE_API_NOT_ENABLED — audience API called without feature flag

Screenshots/Video

• {Include any screenshots or video demonstrating the new feature or fix, if applicable}

Checklist

• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.
• I have added tests that prove my fix is effective or that my feature works.
• I have tested this locally.

Additional Notes

• {Any additional information or context relevant to this PR}

Reference Issue (For employees only. Ignore if you are an outside contributor)

• Closes https://go/j/SDKE-1040

[alexs-mparticle]

Question: Logger.info() Log Level Behavior

Looking at the new Logger.info() implementation in src/logger.ts:328-337:

if (this.logger.info &&
    (this.logLevel === LogLevelType.Verbose || this.logLevel === LogLevelType.Warning)) {
    this.logger.info(msg);
    // ...
}

The info() method is enabled at both Verbose and Warning log levels, which treats it at the same priority as warning().

Questions:

1. Is this the intended behavior? Typically the severity hierarchy is: info < warning < error
2. Should info() messages appear at Warning level, or should they only appear at Verbose level?
3. For the usage logger?.info('RoktManager: Kit attached, Rokt is ready', ErrorCodes.ROKT_KIT_ATTACHED) - is this meant to be visible at Warning level?

Just want to confirm the log level design is intentional. 👍

[alexs-mparticle]

Suggestion: Additional Test Coverage for Edge Cases

The test coverage looks solid overall, but there are a few edge cases that might be worth covering:

Missing Test Scenarios:

1. Logger.info()/warning() when reportingLogger is null/undefined - Ensure it doesn't throw
2. ReportingLogger exceptions - What happens if reportingLogger.warning() or reportingLogger.info() throws an error?

Example scenario:

// Should not crash if reportingLogger throws
logger.warning('test', ErrorCodes.IDENTITY_REQUEST);
// Even if reportingLogger.warning() throws internally

Risk:
If ReportingLogger methods throw exceptions, they could break normal logging flow and potentially impact SDK stability.

Recommendation:
Consider adding defensive error handling around reportingLogger calls, or add tests to verify current behavior handles exceptions gracefully.

Not a blocker, but might prevent future issues. 🛡️

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

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

See analysis details on SonarQube Cloud