fix: handle and log problematic records in data-sink-worker

[mbani01]

This pull request improves error handling and logging in the DataSinkService to make telemetry reporting more robust. The main changes focus on preventing crashes when activity data is missing and ensuring that any errors during telemetry reporting are logged.

Error handling and logging improvements:

• Wrapped the telemetry reporting logic in a try...catch block to ensure any errors during telemetry reporting are caught and logged, preventing the process from crashing. [1] [2]
• Added a warning log when an activity result has a missing data.data payload, including relevant context such as resultId, integrationId, and platform.
• Updated the code to safely access channel from activityData, preventing runtime errors if the data is missing.

---

Note

Low Risk
Low risk: changes are limited to telemetry reporting and logging, adding guards and a try/catch to prevent worker crashes when result payloads are malformed.

Overview
Makes DataSinkService.processResults telemetry reporting more robust by wrapping the per-type telemetry.distribution loop in a try/catch and logging failures instead of crashing.

For IntegrationResultType.ACTIVITY, it now safely reads item.data?.data and logs a warning with result context when the activity payload is missing, while still emitting telemetry with channel left undefined.

^{Written by Cursor Bugbot for commit ff01059. This will update automatically on new commits. Configure here.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

⚠️ Jira Issue Key Missing

Your PR title doesn't contain a Jira issue key. Consider adding it for better traceability.

Example:

• feat: add user authentication (CM-123)
• feat: add user authentication (IN-123)

Projects:

• CM: Community Data Platform
• IN: Insights

Please add a Jira issue key to your PR title.

[github-actions]

⚠️ Jira Issue Key Missing

Your PR title doesn't contain a Jira issue key. Consider adding it for better traceability.

Example:

• feat: add user authentication (CM-123)
• feat: add user authentication (IN-123)

Projects:

• CM: Community Data Platform
• IN: Insights

Please add a Jira issue key to your PR title.

[github-actions]

⚠️ Jira Issue Key Missing

Your PR title doesn't contain a Jira issue key. Consider adding it for better traceability.

Example:

• feat: add user authentication (CM-123)
• feat: add user authentication (IN-123)

Projects:

• CM: Community Data Platform
• IN: Insights

Please add a Jira issue key to your PR title.

[Copilot]

Pull request overview

Improves robustness of telemetry reporting in DataSinkService by preventing runtime errors when activity result payloads are missing and ensuring telemetry failures are logged instead of crashing the worker.

Changes:

• Wraps per-batch telemetry reporting in a try...catch and logs telemetry emission failures.
• Safely reads channel from activity payloads and adds a warning log when data.data is missing.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

activityArgs sets channel to activityData?.channel, which can be undefined. The telemetry client’s normalizeTags passes tag values through without filtering undefined, and DogStatsD expects tag values to be strings/numbers; this can throw and cause the whole telemetry loop to abort (only caught at the outer try/catch). Consider omitting the channel tag when missing or mapping it to a sentinel string like '<not-set>' to avoid telemetry errors/noise.

Suggested change

	channel: activityData?.channel,
	channel: activityData?.channel ?? '<not-set>',