Skip to content

Stale documentation about UniqueOpts #1178

Closed

Description

@mitar

Currently, documentation about UniqueOpts is stale for ByState condition:

	// Warning: Removing any states from the default list (other than `retryable`)
	// forces a fallback to a slower insertion path that takes an advisory lock
	// and performs a look up before insertion. This path is deprecated and should
	// be avoided if possible.

After reading this and setting my list to:

				rivertype.JobStateAvailable,
				rivertype.JobStateRetryable,
				rivertype.JobStateScheduled,

I got an error that pending and running is missing. Looking at the code it looks like this deprecated path has been removed in #614, but docstrings has not been updated.

BTW, I am sad that it is not possible to remove "running" state because now I cannot encode my use case. I have a bridge indexing data from PostgreSQL to ElasticSearch and in some cases I have to index additional documents. So I write their IDs into a table and submit a job to a single worker queue which then loops and reads from the table and process IDs in there until they are all indexed. So during this processing, more document IDs might be written into a table. Maybe current job will pick it up or maybe current job will skip it. This is why I want that it is possible to schedule additional but only one more job after currently running, so that after current job finishes, another one tries to do more work. So I would like to have ByState without "running" option.

Activity

  1. added a commit that references this issue on Mar 23, 2026
    21708ae
  2. brandur commented on Mar 23, 2026

    @brandur
    Contributor

    Thanks. Fixed in #1179.

    Ack on running state: unfortunately as implemented, not requiring these states puts River in some pretty sticky situations when trying to move jobs between common parts of the runner state machine and finding a unique conflict already there. It's potentially resolvable, but maybe not an acceptable level of comprehensibility/complexity.

  3. mitar commented on Mar 23, 2026

    @mitar
    ContributorAuthor

    I wrote my comment in #1179. TLDR: as a user I am surprised that InsertOpts control anything else besides inserting. I would expect that it controls only inserting and not also impose restrictions on state transitioning.

  4. added 2 commits that reference this issue on Mar 23, 2026
    4bfb204
    dc88254
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions