OpenTelemetry: add ability to set StatusCode in errorMapper based on A

[IvanFinochenko]

No description provided.

[IvanFinochenko]

ISSUE #698

[IvanFinochenko]

@grouzen, Hi. When I added A in aspects compiler throws error
inferred type arguments [Nothing,Any,Nothing,Nothing,Unit,Nothing] do not conform to method @@'s type parameter bounds [LowerR <: UpperR,UpperR,LowerE,UpperE >: LowerE,LowerA >: Unit,UpperA >: LowerA] _ <- ZIO.unit @@ span("Child") @@ span[Throwable, Unit]("Root")

but If I set types as in PR it works, but it is not convenient. May be you know how it fix ?

[grouzen]

@IvanFinochenko Thanks for the contribution!
I'll check the aspect error you mentioned later.

[grouzen]

I'm letting you know that I'm playing with the different versions of the ErrorMapper interface because we need to re-imagine it, considering these new requirements. We need to make it straightforward for the end user, and the current one looks messy and non-systematic.

[grouzen]

@IvanFinochenko Hey!
I've come up with the following interface:

final case class StatusMapper[E, A](
  failure: PartialFunction[E, (StatusCode, Option[Throwable])],
  success: PartialFunction[A, (StatusCode, Option[String])]
)

Also, I think we might want to rename the errorMapper parameters to something like statusMapper since we want to map failed and successful cases to status codes.
For the successful part, it is enough to provide just String instead of Throwable.

What do you think?

[IvanFinochenko]

@grouzen Hi
Nice interface, I will try to refactor.
But if we have string in successful part we cannot use method span.recordException or we can make own Exception class and pass this String to message ?

[grouzen]

@grouzen Hi Nice interface, I will try to refactor. But if we have string in successful part we cannot use method span.recordException or we can make own Exception class and pass this String to message ?

In my understanding, we don't need to call recordException for a successful case. This semantics makes sense to me as an application itself doesn't throw exceptions in successful cases, right?
Hope that makes sense.

[grouzen]

@IvanFinochenko Also, I think it would be better to return a case class instead of a tuple as a result for both (failure and success) cases. We can make a type of the second field abstract:

final case class StatusMapper[E, A](
  failure: PartialFunction[E, StatusMapperResult[Throwable]],
  success: PartialFunction[A, StatusMapperResult[String]]
)

object StatusMapper {
  final case class StatusMapperResult[T](statusCode: StatusCode, error: Option[T] = None)
}

It has two benefits:

• named fields that are more convenient for the end user
• error is None by default so that it can be skipped by the end user if not needed in a particular case

[IvanFinochenko]

@grouzen What do we do with String in Successful part? Set description in span.setStatus(errorStatus, description) ?

[grouzen]

@grouzen What do we do with String in Successful part? Set description in span.setStatus(errorStatus, description) ?

Yes

[grouzen]

@IvanFinochenko Hey! How is it going? Do you need any help with it?

[IvanFinochenko]

@grouzen I updated PR

[grouzen]

@IvanFinochenko Please, resolve the conflict. Also, sbt compileExamples needs to be fixed.
Overall, it LGTM and I'm ready to merge it.

[grouzen]

Fix conflicts, please.

[IvanFinochenko]

@grouzen I fixed

[IvanFinochenko]

@grouzen In build strange error. Can you check please ?

[grouzen]

Yeah, I noticed this kind of error a couple of days ago it is not relevant to the main code base so we can forcibly merge the PR, don't worry about it.

[grouzen]

LGTM! Thanks for the contribution!