feat(linkedin-audiences): upgrade API to 202603 behind feature flag#3715
feat(linkedin-audiences): upgrade API to 202603 behind feature flag#3715harsh-joshi99 wants to merge 1 commit intomainfrom
Conversation
- Update versioning-info.ts with canary version 202603 - Add FLAGON_NAME and getApiVersion() helper to constants.ts - Update extendRequest in index.ts to use feature-flagged version - Update batchUpdate in api.ts to accept and use features parameter - Thread features through updateAudience perform/performBatch and processPayload - Add feature flag tests for both stable (202505) and canary (202603) versions - All 36 tests passing 202505 sunsets May 15 2026; this upgrade ensures continuity via safe canary rollout. Feature flag: linkedin-audiences-canary-version Breaking changes analysis in breaking-changes-analysis.md Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
There was a problem hiding this comment.
Pull request overview
Upgrades the LinkedIn Audiences destination to support the 202603 LinkedIn API version behind a feature flag (linkedin-audiences-canary-version), while keeping 202505 as the stable default to allow a safe canary rollout ahead of the 202505 sunset.
Changes:
- Added stable/canary API version constants plus a feature-flag-driven
getApiVersion(features)helper. - Switched request header injection to use the feature-flagged version (and threaded
featuresthrough the updateAudience flow). - Added unit tests for stable vs canary version selection and added a breaking-changes analysis document.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/destination-actions/src/destinations/linkedin-audiences/versioning-info.ts | Defines stable (202505) and canary (202603) API versions. |
| packages/destination-actions/src/destinations/linkedin-audiences/constants.ts | Introduces feature flag name + getApiVersion(features) helper and exports canary version constant. |
| packages/destination-actions/src/destinations/linkedin-audiences/index.ts | Uses getApiVersion(features) to set the LinkedIn-Version header in extendRequest. |
| packages/destination-actions/src/destinations/linkedin-audiences/api.ts | Updates batchUpdate to accept features and use feature-flagged API versioning. |
| packages/destination-actions/src/destinations/linkedin-audiences/updateAudience/index.ts | Threads features into processPayload for both perform and performBatch. |
| packages/destination-actions/src/destinations/linkedin-audiences/updateAudience/functions.ts | Threads features through to batchUpdate. |
| packages/destination-actions/src/destinations/linkedin-audiences/updateAudience/tests/index.test.ts | Adds tests validating stable vs canary LinkedIn-Version behavior. |
| packages/destination-actions/src/destinations/linkedin-audiences/breaking-changes-analysis.md | Adds documented analysis and rollout/testing checklist for 202505 → 202603. |
|
|
||
| ## Summary | ||
|
|
||
| No new DMP Segments API-specific breaking changes were introduced in the 202505–202603 window. The upgrade is primarily driven by **version sunset urgency**: 202505 sunsets on **May 15, 2026** (~1 month from today). Upgrading to 202603 (supported until March 16, 2027) ensures continuity of service. |
There was a problem hiding this comment.
The phrase "(~1 month from today)" will become stale over time and can make this analysis misleading. Consider removing the relative time or anchoring it to a specific date (e.g., "as of 2026-04-13").
|
|
||
| **Impact on our implementation**: Our current code checks `res.status !== 200` for the top-level HTTP response and throws `RetryableError` for non-200 responses. Under 202603, a batch with some valid and some invalid elements may return HTTP `200` at the top level while individual elements have `400` status in the response body. | ||
|
|
||
| **Decision**: The existing error handling remains correct for the overall batch failure case. Per-element error handling is a potential future enhancement but is not a breaking change for the current implementation pattern (batch retries handle transient failures). |
There was a problem hiding this comment.
This section implies per-element failures in a top-level 200 response are effectively handled via retries, but the current implementation only checks res.status !== 200 and does not inspect per-element statuses in the response body. Please update this analysis to reflect that per-element 4xx responses would currently be treated as success (no retry), or add code to detect and surface per-element failures.
| **Decision**: The existing error handling remains correct for the overall batch failure case. Per-element error handling is a potential future enhancement but is not a breaking change for the current implementation pattern (batch retries handle transient failures). | |
| **Decision**: The existing error handling remains correct only for top-level batch failures. Per-element `400` responses inside a top-level `200` response are currently treated as success by our implementation, so they are neither surfaced nor retried. This is a known behavioral gap to monitor during rollout and should be addressed in a future implementation change if element-level failure handling becomes required. |
| headers: { | ||
| 'X-RestLi-Method': 'BATCH_CREATE', | ||
| 'Linkedin-Version': LINKEDIN_API_VERSION // https://learn.microsoft.com/en-us/linkedin/marketing/matched-audiences/create-and-manage-segment-users?view=li-lms-2025-11&tabs=curl | ||
| 'Linkedin-Version': getApiVersion(features) // https://learn.microsoft.com/en-us/linkedin/marketing/matched-audiences/create-and-manage-segment-users?view=li-lms-2025-11&tabs=curl | ||
| }, |
There was a problem hiding this comment.
extendRequest already injects the LinkedIn-Version header for all requests. Setting a per-request version header here (with a different key casing) overrides the default and makes it easier for the versioning behavior to drift between endpoints. Consider relying on extendRequest for the version header (keep only X-RestLi-Method here), or at least standardize the header key casing to a single form across the destination.
| describe('API Version Feature Flag', () => { | ||
| it('should use stable API version by default (no feature flag)', async () => { | ||
| nock(`${BASE_URL}/dmpSegments`) | ||
| .get(/.*/) | ||
| .query(() => true) | ||
| .reply(200, { elements: [{ id: 'dmp_segment_id' }] }) | ||
|
|
||
| const batchUpdateMock = nock(`${BASE_URL}/dmpSegments/dmp_segment_id/users`) | ||
| .post(/.*/, updateUsersRequestBody) | ||
| .matchHeader('linkedin-version', LINKEDIN_API_VERSION) | ||
| .reply(200) |
There was a problem hiding this comment.
These tests only assert the linkedin-version header on the /users request. Since batchUpdate also sets that header explicitly, the tests won’t catch regressions where extendRequest fails to apply the feature-flagged version to other endpoints (e.g., the preceding /dmpSegments GET/POST). Add matchHeader assertions for the /dmpSegments calls as well (or refactor so only extendRequest sets the version header) to ensure the flag truly controls all LinkedIn requests.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3715 +/- ##
==========================================
- Coverage 80.90% 80.70% -0.21%
==========================================
Files 1383 1326 -57
Lines 27632 24666 -2966
Branches 5904 5086 -818
==========================================
- Hits 22355 19906 -2449
+ Misses 4339 3828 -511
+ Partials 938 932 -6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Summary
Upgrades LinkedIn Audiences API from 202505 to 202603, deployed behind feature flag
linkedin-audiences-canary-version.Urgency: 202505 sunsets May 15, 2026 (~1 month away). This upgrade is time-sensitive.
Changes
Version Management
versioning-info.tswith canary version202603alongside stable202505FLAGON_NAME,LINKEDIN_CANARY_API_VERSION, andgetApiVersion(features)helper toconstants.tsextendRequestinindex.tsto use feature-flagged version for theLinkedIn-VersionheaderbatchUpdateinapi.tsto accept and usefeaturesparameterfeaturesthroughupdateAudienceperform/performBatch→processPayloadTesting
linkedin-audiences-canary-versiondestinations/linkedin-audiencesBreaking Changes
No new breaking changes in the 202505 → 202603 range for the DMP Segments API.
Medium Priority (pre-range, context only)
BATCH_CREATE per-element response schema (202502)
throwHttpErrors: falsewith top-level status check; per-element failures are addressed by Centrifuge retriesbreaking-changes-analysis.mdLow Priority / Informational
See
breaking-changes-analysis.mdin the destination directory for the full analysis.Testing Plan
Manual Testing Required
linkedin-audiences-canary-versiondisabled (stable version 202505)linkedin-audiences-canary-versionenabled (canary version 202603)LinkedIn-Versionheader is correct in both casesAutomated Testing
Rollout Plan
202603toLINKEDIN_AUDIENCES_API_VERSION(stable)202505constantRisk Assessment
Risk Level: LOW
LinkedIn-Versionheader value🤖 Generated with Claude Code