Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support UniqueOpts without JobStateRunning in ByState

Abierto
  • ¿Algo no está bien?
#1,183 0 comentarios 2 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
go
Área
backend

Línea de trabajo

Start by tracing the UniqueOpts and InsertOpts definitions and the JobStateRunning handling referenced in this request. Compare the existing uniqueness behavior with the requested pending-versus-running cases; done means insertion skips a duplicate pending job but permits one when the existing job is running, while preserving transactional behavior.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

This is a followup to this issue and my comment here. I want to make a stand-alone feature request. So copying my comment here:

I am a newcomer to River, but explanation why JobStateRunning is required is surprising to me based on the rest of the documentation. UniqueOpts is part of InsertOpts and that to me means that it only controls when the job can be inserted, not how it can transition later on. For my use case (I described in https://github.com/riverqueue/river/issues/1178) I care that (transitionally) I can skip adding additional job if one is already pending, but not running. Jobs are designed so that they could run 100 of them in parallel, they are also idempotent, it is just that it is unnecessary to have more then one at any given time being scheduled to run.

About how many jobs are running in parallel, my understanding is that this is what concurrency limits are for, not insert options.

To me this is also surprising because when as a user I insert a job, it is never in any other state than an initial state. I cannot insert a job in the "running" state. That makes no sense. Only River can move job to a running state. So why would "InsertOps" control how can River move jobs between states? To me "InsertOps" is only about the user - can I as a user insert a job if any job is in a pending state but not yet running?

In fact, to me this is a feature: River should be able to transition any available job to running state. But if River does that, then my insertion (where "running" state is not among UniqueOpts) should transactionally succeed. And this is exactly the behavior I would need. If at any given moment job is not yet running or even not being started to be run, skip adding the job. It is unnecessary. The job which will shortly run will do the job. But if the job is already running, then schedule it. Because it might be that the job running will miss a bit of work.

Lenguaje dominante
Go
Estrellas
5.7k
Forks
187
Merge medio
1 d 11 h
PR fusionados (30 d)
63

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de riverqueue/river

Todos los issues de riverqueue/river

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.