Austin -- what would you think about an option to add SetContext(ctx context.Context) as a method to the statefun.Context interface? Then one could do something like this:
func (f *MyFunc) Invoke(ctx statefun.Context, message statefun.Message) error { logger := NewLogger() ctx.SetContext(ctxzap.ToContext(ctx, logger)) } ... at any point that the context.Context internal to statefun.Context needed to be updated? I think this would work with pretty much anything out there that adds values to context.Context. On Fri, Feb 18, 2022 at 11:12 AM Austin Cawley-Edwards < austin.caw...@gmail.com> wrote: > Looking through the statefun Context interface, it indeed doesn't give > access to the underlying context.Context and the only implementation is > package-private [1]. I don't think there would be a way to update the > statfun.Context interface without introducing breaking changes, but if we > were to make that implementation public, that might be a stopgap solution. > e.g., > > ``` > type StatefunContext struct { > // expose embedded context > context.Context > > // make the mutext private > mu sync.Mutex > > // keep internals private > self Address > caller *Address > storage *storage > response *protocol.FromFunction_InvocationResponse > } > ``` > > You could then do a type assertion in the handlers for this type of > context, and modify the context on it directly. It would be a bit ugly, but > may work. > > ``` > func (s aFunc) Invoke(ctx Context, message Message) error { > if sCtx, ok := ctx.(*statefun.StatefunContext); ok { > sCtx.Context = context.WithValue(sCtx.Context, "logger", aLogger) > } > // ... > } > ``` > > Let me know what you all think, > Austin > > > [1]: > > https://github.com/apache/flink-statefun/blob/1dfe226d85fea05a46c8ffa688175b4c0f2d4900/statefun-sdk-go/v3/pkg/statefun/context.go#L66-L73 > > > On Fri, Feb 18, 2022 at 11:03 AM Galen Warren <ga...@cvillewarrens.com> > wrote: > > > Sorry Austin, I didn't see your response before I replied. Yes, we're > > saying the same thing. > > > > On Fri, Feb 18, 2022 at 10:56 AM Austin Cawley-Edwards < > > austin.caw...@gmail.com> wrote: > > > > > Hey all, jumping in. This makes sense to me – for instance to attach a > > > logger with some common metadata, e.g trace ID for the request? This is > > > common in go to add arbitrary items without updating the method > > signatures, > > > similar to thread local storage in Java. > > > > > > On Fri, Feb 18, 2022 at 10:53 AM Till Rohrmann <trohrm...@apache.org> > > > wrote: > > > > > > > Thanks for the clarification Galen. If you call the other Go > functions, > > > > then you could also pass the other values as separate arguments to > > these > > > > functions, can't you? > > > > > > > > Cheers, > > > > Till > > > > > > > > On Fri, Feb 18, 2022 at 3:31 PM Galen Warren < > ga...@cvillewarrens.com> > > > > wrote: > > > > > > > > > The former. > > > > > > > > > > I think there's potential for confusion here because we're using > the > > > > > word *function > > > > > *in a couple of senses. One sense is a *stateful function*; another > > > sense > > > > > is a *Go function*. > > > > > > > > > > What I'm looking to do is to put values in the Context so that > > > downstream > > > > > Go functions that receive the context can access those values. > Those > > > > > downstream Go functions would be called during one invocation of > the > > > > > stateful function. > > > > > > > > > > On Fri, Feb 18, 2022 at 6:48 AM Till Rohrmann < > trohrm...@apache.org> > > > > > wrote: > > > > > > > > > > > Hi Galen, > > > > > > > > > > > > Am I understanding it correctly, that you would like to set some > > > values > > > > > in > > > > > > the Context of function A that is then accessible in a downstream > > > call > > > > of > > > > > > function B? Or would you like to set a value that is accessible > > once > > > > > > function A is called again (w/ or w/o the same id)? > > > > > > > > > > > > Cheers, > > > > > > Till > > > > > > > > > > > > On Thu, Feb 17, 2022 at 10:59 PM Galen Warren < > > > ga...@cvillewarrens.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > Also, a potentially simpler way to support this would be to > add a > > > > > > > SetContext method to the statefun.Context interface, and have > it > > > > assign > > > > > > the > > > > > > > wrapped context. This would not require changes to the function > > > spec, > > > > > or > > > > > > > anything else, and would be more flexible. > > > > > > > > > > > > > > On Thu, Feb 17, 2022 at 1:05 PM Galen Warren < > > > > ga...@cvillewarrens.com> > > > > > > > wrote: > > > > > > > > > > > > > > > Thanks for the quick reply! > > > > > > > > > > > > > > > > What I'm trying to do is put some things into the context so > > that > > > > > > they're > > > > > > > > available in downstream calls, perhaps in methods with > pointer > > > > > > receivers > > > > > > > to > > > > > > > > the function struct (MyFunc) but also perhaps in methods that > > are > > > > > > further > > > > > > > > downstream that don't have access to MyFunc. If I'm > > understanding > > > > > > > > correctly, your proposal would work for the former but not > the > > > > > latter. > > > > > > > > > > > > > > > > An example would be to put a configured Logger into the > context > > > > via a > > > > > > > > WithLogger method (logging package - knative.dev/pkg/logging > - > > > > > > > pkg.go.dev > > > > > > > > <https://pkg.go.dev/knative.dev/pkg/logging#WithLogger>) and > > > then > > > > > pull > > > > > > > it > > > > > > > > out downstream via FromContext (logging package - > > > > > > > knative.dev/pkg/logging > > > > > > > > - pkg.go.dev < > > > > https://pkg.go.dev/knative.dev/pkg/logging#FromContext > > > > > > >). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Feb 16, 2022 at 5:50 PM Seth Wiesman < > > > sjwies...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > >> Hi Galen, > > > > > > > >> > > > > > > > >> No, that is not currently supported, the current idiomatic > way > > > > would > > > > > > be > > > > > > > to > > > > > > > >> pass those values to the struct implementing the Statefun > > > > interface. > > > > > > > >> > > > > > > > >> > > > > > > > >> type MyFunc struct { someRuntimeInfo string } func (m > *MyFunc) > > > > > > > Invoke(ctx > > > > > > > >> statefun.Context, message statefun.Message) error { } func > > > main() > > > > { > > > > > > > >> builder > > > > > > > >> := statefun.StatefulFunctionsBuilder() > > > > > > > >> f := MyFunc { someRuntimeInfo: "runtime-provided" } > > > > builder.WithSpec > > > > > > > >> (statefun.StatefulFunctionSpec{ FunctionType: > > > > statefun.TypeNameFrom( > > > > > > > >> "example/my-func"), Function: f }) > > > > > > > >> http.Handle("/statefun", builder.AsHandler()) > > > > > > > >> _ = http.ListenAndServe(":8000", nil) } > > > > > > > >> > > > > > > > >> Would this work for you? Or what is the context (pun > intended) > > > you > > > > > are > > > > > > > >> looking for? > > > > > > > >> > > > > > > > >> Seth > > > > > > > >> > > > > > > > >> On Wed, Feb 16, 2022 at 4:35 PM Galen Warren < > > > > > ga...@cvillewarrens.com > > > > > > > > > > > > > > >> wrote: > > > > > > > >> > > > > > > > >> > When stateful functions are invoked, they are passed an > > > instance > > > > > of > > > > > > > >> > statefun.Context, which wraps the context.Context received > > by > > > > the > > > > > > HTTP > > > > > > > >> > request. Is there any way to customize that > context.Context > > > to, > > > > > say, > > > > > > > >> hold > > > > > > > >> > custom values, using ctx.WithValue()? I don't see a way > but > > I > > > > > wanted > > > > > > > to > > > > > > > >> > ask. > > > > > > > >> > > > > > > > > >> > If not, would you be interested in a PR to add this > > > > > functionality? A > > > > > > > >> simple > > > > > > > >> > way might be to add a property to StatefulFunctionSpec, > say: > > > > > > > >> > > > > > > > > >> > TransformContext func(ctx context.Context) context.Context > > > > > > > >> > > > > > > > > >> > ... that, if supplied, would be called to create a > > customized > > > > > > context > > > > > > > >> that > > > > > > > >> > would be used downstream? > > > > > > > >> > > > > > > > > >> > Thanks. > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >