[APM] Some API calls happen without transaction.type

[dgieselaar]

When clicking on a service from the service inventory, and landing on the service overview page, the following requests do not have a transaction.type set:

Unexpected & should be fixed:

• /api/apm/services/{serviceName}/transactions/charts/error_rate (is retried later with transaction type set) Fixed here [APM] transactionType should be required on service-specific endpoints #86893

Expected:

• /api/apm/services/opbeans-ruby/transaction_types
• /api/apm/services/{serviceName}/dependencies

Unclear:

• /api/apm/ui_filters/environments
• /api/apm/services/{serviceName}/metadata/icons
• /api/apm/services/opbeans-ruby/metadata/details
• /api/apm/services/opbeans-ruby/annotation/search
• /api/apm/services/opbeans-ruby/agent_name

The agent name API call doesn't really need it.

I think possibly environments should have it. @formgeist should we filter environments based on the selected transaction type?

For annotations and metadata we should make the same decision, as service.version is being used. I'm inclined to not use transaction type there, as it is not part of the API to create annotations.

[elasticmachine]

Pinging @elastic/apm-ui (Team:apm)

[cauemarcondes]

@formgeist Do you think we should filter by transaction type the metadata and metadata/icons APIs? these are going to be used in the service icons.

[formgeist]

@cauemarcondes The service info shouldn't be filtered by transaction type as they should simply tell the story of the entire service. It's filtered by environment?

[cauemarcondes]

The service info shouldn't be filtered by transaction type as they should simply tell the story of the entire service. It's filtered by environment?

Yes, it is.

[cauemarcondes]

@formgeist and what do you think about this environment API (/api/apm/ui_filters/environments)? should it be filtered by transaction type too?

[sorenlouv]

what do you think about this environment API (/api/apm/ui_filters/environments)? should it be filtered by transaction type too?

No, environment should not be filtered by transaction type. The hierarchy is:

1. service.name
2. service.environment
3. transaction.type
4. everything else

Example
A service is selected via inventory page: service.environment is only filtered by service.name. transaction.type is filtered by both service.name and service.environment.

[cauemarcondes]

service.environment is only filtered by service.name

Today environment is filtered by start, end, and service name. Should we keep the start and end?

transaction.type is filtered by both service.name and service.environment

Today transaction type is filtered by start, end, and service name. I'm going to add the environment filter here too then.

[cauemarcondes]

@sqren before I go on and start changing some code I'd like to double-check some stuff with you.

The above image filters the transaction types by environment. The user-interaction transaction type was selected when I had another environment selected, by changing the environment, and filtering the transaction types by it, the previously selected option is no longer available. I can of course change the logic to check if the selected transaction type is no longer available and select one of the available options, but should we do it?

Now, this image shows the current behavior, where the transaction types is not filtered by environment, in this case user-interaction is still available to the user under the transaction types filter. I think he can easily switch to another transaction type to show some data.

Like I said I just want to double-check if it is worth doing this change.

[sorenlouv]

Today environment is filtered by start, end, and service name. Should we keep the start and end?

True, I left out the date range. Both environment and transaction type should be filtered by this.

[sorenlouv]

I can of course change the logic to check if the selected transaction type is no longer available and select one of the available options, but should we do it?

Good point. I think there are two options:

1. Selecting environment should reset transaction.type (either to undefined or the default type), or
2. If the selected transaction type doesn't exist we should redirect to the default transaction type

[cauemarcondes]

New issue created to filter the transaction types by environment #87616

[formgeist]

@cauemarcondes Clarification from my talk with @alex-fedotyev - we want to keep the service metadata filtered by queries, but not filtered by the transaction type. So I think we can strike that from the list as well.