-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add lambda-otel4s module #459
base: main
Are you sure you want to change the base?
Conversation
6b6999d
to
4242256
Compare
Currently pointed at a local snapshot so CI will definitely fail, as otel4s main has |
lambda-otel4s/shared/src/main/scala/feral/lambda/otel4s/FaasAttributes.scala
Outdated
Show resolved
Hide resolved
lambda-otel4s/shared/src/main/scala/feral/lambda/otel4s/TracedHandler.scala
Outdated
Show resolved
Hide resolved
lambda-otel4s/shared/src/main/scala/feral/lambda/otel4s/package.scala
Outdated
Show resolved
Hide resolved
@iRevive Updated all the attributes and removed semconv-experimental Would appreciate another look when you have time |
@alexcardell the changes look good. We still need to wait for a release of https://github.com/http4s/http4s-otel4s-middleware, right? |
The middleware would be useful for the example, but I don't believe it's necessary otherwise |
This is to allow consumers the choice of natchez or otel4s No breaking changes except requiring a `feral.lambda.natchez._` import
Co-authored-by: Maksym Ochenashko <[email protected]>
Fixed the 0.9 issues, good to go |
@iRevive is v0.10.0 coming soon? |
import feral.lambda.natchez.KernelSource | ||
import org.typelevel.ci._ | ||
|
||
protected trait KernelSources { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of putting these in the package object, we can put them in the companion object for KernelSource
. Then they will automatically be in implicit scope without an import.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alexcardell Can you look into this as well? 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@armanbilge done :)
We are two PRs away from 0.10.0: Both are implemented, some minor changes (docs, etc) may be required. I think we will have 0.10.0 next week. |
I am going hang on for otel4s v0.10.0 to avoid back-to-back breaking releases! |
|
so fast!! |
Updated |
libraryDependencies ++= Seq( | ||
"org.typelevel" %%% "otel4s-core-trace" % otel4sVersion, | ||
"org.typelevel" %%% "otel4s-sdk-trace-testkit" % otel4sVersion % Test, | ||
"org.typelevel" %%% "otel4s-semconv-experimental" % otel4sVersion % Test, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Experimental (incubating) semantic conventions. Breaking changes expected. Library instrumentation SHOULD NOT depend on this.
@iRevive should we be concerned? Gah, it's Test
, I'm sorry. It's all fine :)
build.sbt
Outdated
"org.tpolecat" %%% "skunk-core" % "0.6.4" | ||
"org.tpolecat" %%% "skunk-core" % "0.6.3" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this rolled back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The answer to this question is lost to time
If there was a reason I've forgotten, but it's probably a mistake
Bumped back
object TracedHandler { | ||
|
||
def apply[F[_]: Monad: Tracer, Event, Result]( | ||
handler: Event => F[Option[Result]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
handler: Event => F[Option[Result]] | |
handler: F[Option[Result]] |
We don't need to pass the event explicitly, because the user obtains it from the Invocation
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
package feral.lambda | ||
package feral.lambda.natchez |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add Scalafix migrations for these renames?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay so I've added inputs and outputs but what's the common practice for adding the new v0.3.0 dependency, to run those tests? Do we require a 0.2->0.3 subproject and a 0.3->0.4 subproject?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the examples in cats have subprojects per version, I will work on that later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of more subprojects, I wonder if we can just delete / replace the old migrations with the new ones since we are doing a version bump? I would prefer not to maintain them forever esp. if Scalafix/Scalameta may issue deprecations in the future 🤔
These migrations are already configured in Scala Steward with a hard-coded version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, well I added the second subproject (plus shuffling the old one into a nested directory) before reading that
If it can be deleted, great!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed
import java.io.ByteArrayOutputStream | ||
import java.util.concurrent.atomic.AtomicInteger | ||
|
||
class TracedHandlerSuite extends CatsEffectSuite { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we avoid the substantial duplication/splitting of these suite? It looks like you based these on some tests that needed extra machinery because they were testing the platform-specific integration. But I think in your situation it should be possible to test TracedHandler
using pure code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure thing, makes sense
eb990d6
to
bb2970f
Compare
Supercedes #456
Discussion
There might be some extra utilities worth exposing to make dealing with batched events (like SQS events) easier -- most likely the context the user wants is on the Record, not the batched Event, but this is pretty equivalent to the existing Natchez module
This is targeting otel4s 0.10.0
Links
https://opentelemetry.io/docs/specs/semconv/faas/aws-lambda/
https://opentelemetry.io/docs/specs/semconv/faas/faas-spans/