Skip to content
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

support generic lambda.HandlerFunc for otellambda #3660

Open
jan-xyz opened this issue Mar 30, 2023 · 3 comments
Open

support generic lambda.HandlerFunc for otellambda #3660

jan-xyz opened this issue Mar 30, 2023 · 3 comments

Comments

@jan-xyz
Copy link

jan-xyz commented Mar 30, 2023

The Go lambda framework now has support for a generic signature that verifies that the handler has the correct signature. The new functions are

// function type
lambda.StartHandlerFunc

// struct type
lambda.StartHandler
lambda.StartHandlerWithContext

that doesn't work anymore with the otellambda.InstrumentHandler. Can we add support for the generic types? With a bit of direction and a thumbs up, I could also contribute this.

@rackerWard
Copy link

How would you implement in Go an API to accept the different handler function declaration signatures without creating a uniquely named function for each kind?

Lambda handlers can be of the following formats.

func()
func(context)
func(context, event)
func(event)

func() error
func(context) error
func(context, event) error
func(event) error

func() (response, error)
func(context) (response, error
func(context, event) (response, error)
func(event) (response, error)

@jan-xyz
Copy link
Author

jan-xyz commented Aug 22, 2023

I don't think it is necessary to support all permutations and only provide an additional function that can deal with the type that is also used by StartHandlerFunc:

// HandlerFunc represents a valid input with two arguments and two returns as described by Start
type HandlerFunc[TIn, TOut any] interface {
	func(context.Context, TIn) (TOut, error)
}

This limits it basically to func(context, event) (response, error), which is the most common use-case probably. All other options are a subset of this anyways and can be implemented with functions that just don't use the parameters and return values that the interface provides.

@lukasmalkmus
Copy link

lukasmalkmus commented May 21, 2024

@jan-xyz Have you made any progress on this?

Seeing #5545 and #5546, I guess, no?

I was initially very happy to stumble onto those packages. Some rough edges here and there - like this issue - but overall it works just fine. Sad to see those two packages being deprecated.

Not sure if I'm up to becoming an owner just yet, tho.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants