Track toast errors using apm-rum

[maryam-saeidi]

Closes https://github.com/elastic/observability-dev/issues/4022

Summary

In this PR, we are capturing toast errors using apm-rum:

label.errorType: ToastError

Screen.Recording.2025-04-14.at.12.23.53.mov

ErrorType is available in labels which this feature was added to the rum agent in this PR.

🧪 How to test

Add the following to your kibana.yml file:

elastic.apm.active: true
elastic.apm.transactionSampleRate: 1.0
elastic.apm.environment: yourName <-- Change to your name

Throw a toast error

Add this code to a page as alerts page and visit http://localhost:5601/kibana/app/observability/alerts

useEffect(() => {
    const error = new Error('Mary test error > toasts.addError');
    toasts.addError(error, { title: 'Testing error toast', toastMessage: error.message });
    toasts.addDanger('Testing danger toast');
  }, []);

Then visit kibana-cloud-apm.elastic.dev filtered for yourName in the environment.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 530ec68

Metrics [docs]

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
core	433.2KB	433.5KB	+254.0B

History

• 💛 Build #292211 was flaky 7d0ff26

cc @maryam-saeidi

[kpatticha]

LGTM, thanks for adding this.

I noticed that some applications use notifications.toasts.danger — for example, APM does here.

Thankfully, it's not used in many places, so I'm wondering — should we also capture errors in those cases, or should we agree on a single, consistent way to display error toasts?

[maryam-saeidi]

should we also capture errors in those cases, or should we agree on a single, consistent way to display error toasts?

@kpatticha Do you mean making it clear when to use danger vs error toasts? (i.e., not using danger in case of an error)

[kpatticha]

should we also capture errors in those cases, or should we agree on a single, consistent way to display error toasts?

@kpatticha Do you mean making it clear when to use danger vs error toasts? (i.e., not using danger in case of an error)

There are currently two ways to display toast messages in Kibana:

1. using the Kibana React notification service
   

   kibana/src/platform/plugins/shared/kibana_react/public/notifications/types.ts

   Lines 22 to 27 in 1017c22

   	export interface KibanaReactNotifications {
   	toasts: {
   	show: (input: ToastInput) => void;
   	success: (input: ToastInput) => void;
   	warning: (input: ToastInput) => void;
   	danger: (input: ToastInput) => void;

2. using notification service in the core package
   

   kibana/src/core/packages/notifications/browser/src/types.ts

   Lines 70 to 78 in 1017c22

   	export interface IToasts {
   	get$: () => Observable<Toast[]>;
   	add: (toastOrTitle: ToastInput) => Toast;
   	remove: (toastOrId: Toast | string) => void;
   	addInfo: (toastOrTitle: ToastInput, options?: any) => Toast;
   	addSuccess: (toastOrTitle: ToastInput, options?: any) => Toast;
   	addWarning: (toastOrTitle: ToastInput, options?: any) => Toast;
   	addDanger: (toastOrTitle: ToastInput, options?: any) => Toast;
   	addError: (error: Error, options: ErrorToastOptions) => Toast;

It seems Infra and APM codebase still uses in some places the first approach. As a result, error messages shown this way won't be captured using apm-rum.

I'm not sure why these apps are still using the first approach, or why both methods for showing toasts still exist—it might just be legacy code.?

Would it make sense to create a ticket to align on a single, consistent approach?

[maryam-saeidi]

Would it make sense to create a ticket to align on a single, consistent approach?

YES! Here is the ticket: https://github.com/elastic/observability-dev/issues/4456

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 217948 locally

[maryam-saeidi]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

[kibanamachine]

Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync.

[maryam-saeidi]

💚 All backports created successfully

Status	Branch	Result
✅	9.0

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation