Cannot test work that inserts jobs using river.ClientFromContext
#512
Comments
|
I actually just encountered this yesterday! Rather than expose a setter for the context value or key, I’m trying to build a test helper that executes a single job. I think this can be a huge improvement for testability. Are you testing with a job row that you’ve actually inserted, or just a simulated job struct you’ve constructed yourself? |
We were previously using `context.Background()` in some situations to avoid cancellation of things that really shouldn't be cancelled by the user context cancellation. However, we can now do that with `context.WithoutCancel` instead in order to preserve context values without any cancellation or deadline. Fixes #512.
We were previously using `context.Background()` in some situations to avoid cancellation of things that really shouldn't be cancelled by the user context cancellation. However, we can now do that with `context.WithoutCancel` instead in order to preserve context values without any cancellation or deadline. Fixes #512.
|
Should be resolved by #514 in the next release, thanks for the report! |
|
I think your comment refers to #511, not this issue. Yeah, a test helper sounds great. I am testing with a simulated worker struct, like: w := scheduled_sync_worker.New(scheduled_sync_worker.Input{})
Expect(w.Work(ctx, &river.Job[scheduled_sync_worker.Args]{JobRow: &rivertype.JobRow{ID: 5}, Args: scheduled_sync_worker.Args{}})).To(Succeed()) |
|
D’oh, yes, sorry 😆 I have some details to work out with this test helper but I think that’s gotta be the real answer here. For a workaround, maybe define a helper function that falls back to extracting the client from an alternate context key you only use in tests. Not ideal though. |
|
Yup, that is what I ended up doing, not a huge problem but would be nice to avoid critical paths that are different when running unit tests, as you already know :) |
|
I'm pretty sure this was accidentally closed. |
|
@staugaard you're right, it’s actually #526 which provides a fix for this issue. |
We were previously using `context.Background()` in some situations to avoid cancellation of things that really shouldn't be cancelled by the user context cancellation. However, we can now do that with `context.WithoutCancel` instead in order to preserve context values without any cancellation or deadline. Fixes riverqueue#512.
If I use
river.ClientFromContext()within a job, and test it using theWorkmethod (as docs suggest), I cannot insert the client into the context. Could be solved by adding ariver.ContextWithClienthelper, exposingctxKey, etc.The text was updated successfully, but these errors were encountered: