fix(context): forward all BucketingAttributes to ExperienceManager

[abbaseya]

Summary

Context.runExperience and Context.runExperiences rebuilt a fresh attributes object with only four hardcoded keys (visitorProperties, locationProperties, updateVisitorProperties, environment) before forwarding to ExperienceManager.selectVariation / selectVariations. Every other BucketingAttributes field — enableTracking, forceVariationId, ignoreLocationProperties, typeCasting, experienceKeys — was silently dropped.

The most user-visible consequence: a caller invoking context.runExperience(key, { enableTracking: false }) still fires the bucketing track event, because by the time the call reaches DataManager._getBucketingByField (which destructures enableTracking = true as a default), the field has been discarded one layer up. Same for forceVariationId (the forced variation was never honored) and ignoreLocationProperties.

Root cause

A whitelist-then-rebuild pattern in Context instead of spread-then-override. Two transforms must happen at the Context layer:

1. visitorProperties must be merged with stored visitor props via getVisitorProperties().
2. environment must default to this._environment when the caller omits it.

Everything else can pass through unmodified; downstream destructures by name and ignores unknown keys.

Fix

// before
{
  visitorProperties,
  locationProperties: attributes?.locationProperties,
  updateVisitorProperties: attributes?.updateVisitorProperties,
  environment: attributes?.environment || this._environment
}

// after
{
  ...attributes,
  visitorProperties,
  environment: attributes?.environment || this._environment
}

Applied identically to runExperience (line 135) and runExperiences (line 190).

{...undefined} evaluates to {} in JS, so the optional-attributes case is safe.

Tests

Added two cases in packages/js-sdk/tests/context.tests.ts:

• Should forward BucketingAttributes (enableTracking, forceVariationId, ignoreLocationProperties) through runExperience
• Should forward BucketingAttributes (enableTracking, forceVariationId, ignoreLocationProperties) through runExperiences

Both monkey-patch experienceManager.selectVariation / selectVariations to capture the attributes argument, then assert the previously-dropped fields are forwarded. Use enableTracking: false to suppress the tracking request so the tests stay deterministic.

Test plan

• yarn test:mocha from packages/js-sdk/ — 143 passing, 0 failing
• yarn lint in packages/js-sdk/ — clean
• Existing Shoud successfully get variation from specific experience and Shoud successfully get variations across all experiences still pass (no regression in the standard path)

Notes

• Fix is API-surface-neutral. Callers that were never passing the dropped fields see no change. Callers that were passing them and silently getting the default behavior will now get the documented behavior — this is what they expected from the public BucketingAttributes type all along.
• No changes to BucketingAttributes typing, DataManager, ExperienceManager, or any downstream layer.

🤖 Generated with Claude Code

[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

[gemini-code-assist]

Code Review

This pull request updates the Context class to forward all attributes to the ExperienceManager using the spread operator, enabling support for properties like enableTracking and forceVariationId. Corresponding tests were added to verify this behavior. However, feedback indicates that the Context layer still emits SystemEvents.BUCKETING events even when enableTracking is set to false. It is recommended to conditionally suppress these events based on the attribute flag and to update the test suite to verify this suppression.