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

Multi-approval task accepts a repeat vote from a team-assigned reviewer with HTTP 200 and drops it

Abierto
  • ¿Algo no está bien?
#35,992 0 comentarios 0 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
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
api, backend, testing

Línea de trabajo

Start with WorkflowHandler.handleMultiApproval in governance/workflows/WorkflowHandler.java, then trace how TaskWorkflowHandler.resolveWorkflowTask and TaskRepository.requireAssigneeForWorkflowApproval handle repeat votes by team and direct user assignees. Extend WorkflowDefinitionResourceIT.test_WorkflowApprovalThresholdReturnsOpenTaskUntilThresholdIsMet with the team-assignee case. Done when both assignee types receive the same 4xx with an already-voted message on a repeat vote, and the voter remains listed once.

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

Descripción

Problem

On a multi-approval workflow task (a userApprovalTask node with approvalThreshold above 1), a reviewer who is assigned through a team can vote twice. The second POST /api/v1/tasks/{id}/resolve returns HTTP 200 with the task still Open, and the vote is dropped with only a server log line. The caller cannot tell a recorded vote from an ignored one, and a reviewer cannot change a vote.

Why it happens, from the code on main:

  • WorkflowHandler.handleMultiApproval (governance/workflows/WorkflowHandler.java, around lines 1425-1428) returns false when the voter is already in approversList or rejectersList, logging [MultiApproval] User '...' has already voted on this task. resolveTaskWithFreshReads turns false into WAITING_FOR_VOTES, and TaskWorkflowHandler.resolveWorkflowTask answers 200 with the refreshed open task.
  • A reviewer assigned directly as a user does not hit this path a second time, because removeTaskFromVoterFeedForTaskEntity drops the user from task.assignees after the first vote and TaskRepository.requireAssigneeForWorkflowApproval then answers 403. A team entry is never removed from task.assignees (the remover matches assignee names against the user name), so a team member still passes the assignee check and reaches the silent drop.

Evidence from a throwaway integration test that set the seeded RequestApprovalTaskWorkflow review node to approvalThreshold 2 and reviewed an ontology release with a team of two members as the reviewer. Member M1 approved, then approved again:

m1-approve        | HTTP 200 in 4386ms body: status=Open stage=review assignees=[team:..._team] ...
after-m1-approve  flowable | vars={approversList=[..._m1], approvalThreshold=2, votedUsers=[..._m1], ...}
m1-approve-again  | HTTP 200 in 1153ms body: status=Open stage=review assignees=[team:..._team] ...
after-m1-approve-again flowable | vars={approversList=[..._m1], approvalThreshold=2, votedUsers=[..._m1], ...}

The same test showed the direct-user case for comparison: the second vote by user R1 returned HTTP 403 ... operations [ResolveTask] not allowed.

What we want

A repeat vote on a multi-approval task is refused with an explicit error (409 or 403, consistent for user and team assignees) instead of a 200 that drops the vote. The response should say the caller has already voted on this task.

Done when
  • A reviewer assigned through a team who resolves the same multi-approval task twice gets a 4xx on the second call, and approversList/rejectersList still list them once.
  • A reviewer assigned directly as a user gets the same status code on a repeat vote.
  • WorkflowDefinitionResourceIT.test_WorkflowApprovalThresholdReturnsOpenTaskUntilThresholdIsMet gains a team-assignee case that asserts the refusal.

Found while building #35983 (ontology release review rules), which does not change this behavior.

Lenguaje dominante
TypeScript
Estrellas
15.4k
Forks
2.4k
Merge medio
1 d 1 h
PR fusionados (30 d)
699

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 open-metadata/OpenMetadata

Todos los issues de open-metadata/OpenMetadata

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.