Currently there seems to be no official way to set keys in metadata at the end of the job run. I want to add additional metadata in WorkEnd but it looks this is not possible. The only official way is river.RecordOutput which sets the output key only.
I can use driver.GetExecutor().JobUpdate with riverdriver.JobUpdateParams but API says "API is not stable. DO NOT USE." Also, downside of using this is that it makes another database request instead of just adding to metadata in ctx which would be merged at the end when executor updates the job row.
There is already internal jobexecutor.ContextKeyMetadataUpdates with tests that metadata updates using it works. I suggest you expose simple API to set keys on it, like river.SetMetadata(ctx, key, value). Such helper could also check that key does not have river: prefix to never conflict with river keys.
My use case is that we use in our codebase rich errors using this package. It records stack trace and additional structured details. We want that in the case of an error to extract that additional information from the error and record it. It looks like metadata is the right place to store it (river by default just stores the message as returned from .Error() and not other error payload). And we can use WorkEnd to do that.
Currently there seems to be no official way to set keys in metadata at the end of the job run. I want to add additional metadata in
WorkEndbut it looks this is not possible. The only official way isriver.RecordOutputwhich sets the output key only.I can use
driver.GetExecutor().JobUpdatewithriverdriver.JobUpdateParamsbut API says "API is not stable. DO NOT USE." Also, downside of using this is that it makes another database request instead of just adding to metadata in ctx which would be merged at the end when executor updates the job row.There is already internal
jobexecutor.ContextKeyMetadataUpdateswith tests that metadata updates using it works. I suggest you expose simple API to set keys on it, likeriver.SetMetadata(ctx, key, value). Such helper could also check that key does not haveriver:prefix to never conflict with river keys.My use case is that we use in our codebase rich errors using this package. It records stack trace and additional structured details. We want that in the case of an error to extract that additional information from the error and record it. It looks like metadata is the right place to store it (river by default just stores the message as returned from
.Error()and not other error payload). And we can useWorkEndto do that.