Skip to content

Let job args return plugins like they can for hooks/middleware - #1337

Open
brandur wants to merge 1 commit into
masterfrom
brandur-job-plugins
Open

Let job args return plugins like they can for hooks/middleware#1337
brandur wants to merge 1 commit into
masterfrom
brandur-job-plugins

Conversation

@brandur

@brandur brandur commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Here, implement a job args jobArgsWithPlugins interface that lets job
args return a set of Plugins. This follows up the addition of plugins
in #1284, and makes the functionality symmetrical to what's available
with hooks/middleware. I would have done this before, but I forgot that
you could do this until I was looking at docs today. As in #1284 for
client config, Hooks and Middleware continue to be supported on job
args and have not yet been deprecated.

type EmailArgs struct {
    To string `json:"to"`
}

func (EmailArgs) Kind() string { return "email" }

func (EmailArgs) Plugins() []rivertype.Plugin {
    return []rivertype.Plugin{
        &EmailPlugin{},
    }
}

type EmailPlugin struct {
    river.PluginDefaults
}

func (p *EmailPlugin) WorkBegin(ctx context.Context, job *rivertype.JobRow) error {
    return nil
}

I also had Codex look for opportunities for implementation clean up
since all of this was feeling like a few too many LOCs. It was able to
clean up ~85 LOCs net, with the main change being to get rid of
PluginLookupInterface + emptyPluginLookup. This removes a layer of
indirection, which is good, but also emptyPluginLookup had become less
useful due to River installing default middleware (ResumableMiddleware)
on all clients whether any has been specified by a client or not.

Here, implement a job args `jobArgsWithPlugins` interface that lets job
args return a set of `Plugins`. This follows up the addition of plugins
in #1284, and makes the functionality symmetrical to what's available
with hooks/middleware. I would have done this before, but I forgot that
you could do this until I was looking at docs today. As in #1284 for
client config, `Hooks` and `Middleware` continue to be supported on job
args and have not yet been deprecated.

    type EmailArgs struct {
        To string `json:"to"`
    }

    func (EmailArgs) Kind() string { return "email" }

    func (EmailArgs) Plugins() []rivertype.Plugin {
        return []rivertype.Plugin{
            &EmailPlugin{},
        }
    }

    type EmailPlugin struct {
        river.PluginDefaults
    }

    func (p *EmailPlugin) WorkBegin(ctx context.Context, job *rivertype.JobRow) error {
        return nil
    }

I also had Codex look for opportunities for implementation clean up
since all of this was feeling like a few too many LOCs. It was able to
clean up ~85 LOCs net, with the main change being to get rid of
`PluginLookupInterface` + `emptyPluginLookup`. This removes a layer of
indirection, which is good, but also `emptyPluginLookup` had become less
useful due to River installing default middleware (`ResumableMiddleware`)
on all clients whether any has been specified by a client or not.
@brandur
brandur force-pushed the brandur-job-plugins branch from 56c927f to 3f6cc5d Compare July 30, 2026 19:20
@brandur
brandur requested a review from bgentry July 30, 2026 19:28
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

Successfully merging this pull request may close these issues.

1 participant