Cyclic import issue: worker registration, service dependencies, and job enqueuing

[RobinLbt]

I'm integrating River into my Go monolith and encountering cyclic import issues due to how dependencies are structured.
I'd appreciate some advice on the recommended patterns to resolve this.

My Setup:

I have a service package containing core business logic methods used throughout my backend.
I have a dedicated riverpkg package where I initialize the river.Client and intend to register workers.
I have a jobs package where river.Worker implementations are defined.

The Issue:

The cyclic import arises from these dependencies:

• Worker Registration: My riverpkg needs to import jobs (to get worker types) and potentially service (to inject service dependencies into the workers during river.NewClient setup).

• Job Dependencies: Workers within the jobs package need to execute business logic, requiring them to import and call methods from the service package.

• Job Enqueuing: Methods within my service package need to enqueue new background jobs, requiring them to import riverpkg to access the river.Client instance (Insert method).

This creates a dependency loop: riverpkg → jobs → service → riverpkg.

Request for Advice:

What are the best practices or recommended patterns with River for structuring an application to avoid this common dependency cycle?

Specifically, how can I cleanly:

• Inject service dependencies into workers?
• Allow services to enqueue jobs?
• Initialize the River client and register workers without creating import cycles?

Thanks for your guidance!

[brandur]

→ service → riverpkg

It sounds like this last step is the piece that's the problem. Did you see the ClientFromContext function that lets you pull a client from context within a worker?

https://riverqueue.com/docs/context-client#_top

Use of that might let you skip needing the specific River client instance defined in riverpkg, and avoid the cross dependency.