For dotnet code, if a different DLL reports an error, the grabbed interface is incorrect

[wajika]

I tried to upgrade Elastic.Apm.NetCoreAll to 1.13.0, then started the service and debugged an interface, the service got an error (similar to Elastic.Apm.NetCoreAll compatibility issues), that's not the point.
I am operating the interface "searchVideoByProductNumber", and then there is an error in the dependency package. Why is the http500 error in the interface "searchVideoByProductNumber" recorded? Rather than accurate to the dependency package error?

This is not a very urgent issue, but I am a little interested to know the answer.
Thanks in advance for taking the time to answer me.

2022-01-17 15:11:29 ERROR 3d55b1816bb2a446a848550a29d1a752 154af42ba8fa5346 Method not found: 'Void Elastic.Apm.Api.IExecutionSegment.CaptureException(System.Exception, System.String, Boolean, System.String)'.
System.MissingMethodException: Method not found: 'Void Elastic.Apm.Api.IExecutionSegment.CaptureException(System.Exception, System.String, Boolean, System.String)'.
   at Lonsid.APM.LonsidExceptionFilter.<>c__DisplayClass1_0.<HandleAndWrapException>b__0()
   at System.Threading.Tasks.Task.InnerInvoke()
   at System.Threading.Tasks.Task.<>c.<.cctor>b__274_0(Object obj)
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location where exception was thrown ---
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location where exception was thrown ---
   at Lonsid.APM.LonsidExceptionFilter.HandleAndWrapException(ExceptionContext context)
   at Lonsid.APM.LonsidExceptionFilter.OnExceptionAsync(ExceptionContext context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextExceptionFilterAsync>g__Awaited|25_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
2022-01-17 15:11:30 ERROR   An unhandled exception has occurred while executing the request.
System.MissingMethodException: Method not found: 'Void Elastic.Apm.Api.IExecutionSegment.CaptureException(System.Exception, System.String, Boolean, System.String)'.
   at Lonsid.APM.ExceptionEventHandler.HandleEvent(AbpHandledExceptionData eventData)
--- End of stack trace from previous location where exception was thrown ---
   at Abp.Events.Bus.EventBus.Trigger(Type eventType, Object eventSource, IEventData eventData)
   at Abp.Events.Bus.EventBus.Trigger[TEventData](Object eventSource, TEventData eventData)
   at Abp.AspNetCore.Mvc.ExceptionHandling.AbpExceptionFilter.HandleAndWrapException(ExceptionContext context, WrapResultAttribute wrapResultAttribute)
   at Abp.AspNetCore.Mvc.ExceptionHandling.AbpExceptionFilter.OnException(ExceptionContext context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeNextResourceFilter>g__Awaited|24_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Rethrow(ResourceExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Elastic.Apm.AspNetCore.ApmMiddleware.InvokeAsync(HttpContext context)
   at Lonsid.Runtime.Session.PSSO.LonsidPSSOMiddleware.Invoke(HttpContext context)
   at Lonsid.AC.Authentication.JwtBearer.JwtTokenMiddleware.<>c__DisplayClass0_0.<<UseJwtTokenMiddleware>b__0>d.MoveNext() in C:\Users\wwx\Desktop\lonsid\Lonsid.AC\Lonsid.AC.Web.Core\Authentication\JwtBearer\JwtTokenMiddleware.cs:line 22
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

[GregKalapos]

@wajika I'm not sure I fully get the question, nevertheless let me share a few comments that may help. If the question is not answered, feel free to follow up.

The transaction name comes from the url. When the request comes in, a transaction is created for it and the name of it will be based on the url of the request. If any error happens during the request, an additional error will be created (this is a separate error object). You'll see this error on the errors tab - and then additionally the error will be associated with the transaction.

So, to this question:

Why is the http500 error in the interface "searchVideoByProductNumber" recorded?

The error is just associated with it - if you look at the error index you'll see fields like transaction_id, parent_id, trace_id - this is how an error object is associated to traces/transactions. You can click "View related error" and that'll show you the error itself. The reason you see it on searchVideoByProductNumber is because that was the active transaction during the error.

Rather than accurate to the dependency package error?

I'm afraid I don't get this part of the question. Do you mean it should be associated with something else other than the transaction? If so, how should it look like?

[wajika]

The transaction name comes from the url. When the request comes in, a transaction is created for it and the name of it will be based on the url of the request. If any error happens during the request, an additional error will be created (this is a separate error object).

According to what you mean, I understand that the first generated span points to the request url. If this reuqest generates an error, apm will create a new error record (that is, a separate record will be inserted into apm-x-error-x) , it has nothing to do with the address of the request url.

and then additionally the error will be associated with the transaction.

So why is the error still bound to the request url?

Do you mean it should be associated with something else other than the transaction? If so, how should it look like?

I also don't know how to handle this is the best, but is it possible to bind to this servicename instead of request url.

Assuming that two errors occur in one request, will the first error cover the second one? I encountered it once, because of some problems with the apm agent, overwriting the error record of my service, because the apm error will appear in advance.

I'm sorry, my english is poor, I don't know if you understand what I mean.

[GregKalapos]

So why is the error still bound to the request url?

This happens on the UI. So what we try to achieve here is that if there was one or more errors during the request with a specific request url, we show those errors to you on the waterflow where you see the specific request with the specific request url.

I also don't know how to handle this is the best, but is it possible to bind to this servicename instead of request url.

We also have a separate errors tab where we only show the errors - without the request url. But you are right in that we always show the error on the transaction. From what I know there is no way to make them disappear from the transaction (other than manually manipulating the index and removing the reference to the transaction).

Assuming that two errors occur in one request, will the first error cover the second one?

No, in that case, you'll se both, like this:

Can you maybe describe what your expectation would be? On your first screenshot above you show a request with 1 error. You'd see the same error if you click on the "Errors" tab, but without the association to the given url. So we already have the option to see the errors without the transactions (or urls). I'm just wondering if this maybe already gives you what you need.