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

[Bug][Jira/DORA] Extra JQL does not isolate projects sharing the same Jira board

Abierto
  • ¿Algo no está bien?
#9,151 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@veetmoradiya3628 ya está trabajando en esto.

Desde el 21/9/2026.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
data-engineering, devops

Línea de trabajo

Start by tracing issue_collector.go and task_data.go, then follow project_mapping and board_issues into incident_from_issue_generator.go. Compare how rendered Extra JQL and shared-board state are handled across collection and DORA conversion. Done means an end-to-end regression test with two projects sharing a Jira board keeps each project's issues and incidents isolated.

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

Descripción

Search before asking

  • I searched the existing issues and found no report covering this specific isolation problem.

Related work:

  • #8955 describes the original requirement for component-based scoping of shared Jira boards.
  • #8972 added Extra JQL support.
  • #9035 added {{.ProjectName}} support to Extra JQL.
  • #8198 and #6768 describe related shared-board and cross-project data problems, but not this behavior.

What happened

Two DevLake projects use the same Jira connection and board. Jira components identify the deployable units, and both projects share this scope configuration:

component = "{{.ProjectName}}"

For a project named service-alpha, DevLake renders and executes the expected query:

filter = 12345 AND (component = "service-alpha")
AND updated >= '2026/09/18 12:45'
ORDER BY created ASC

The observed incremental request completed successfully, but the extractor found zero new raw issue rows and convertIssues processed zero issues. Nevertheless, the subsequent DORA ConvertIssuesToIncidents subtask converted 13 existing issues into incidents for service-alpha. Those issues included components belonging to other deployable units.

A direct Jira query returned zero matching bugs for service-alpha, while the shared board contained hundreds of bugs overall. This confirms that the unrelated incidents were not returned by the rendered Extra JQL query.

The behavior appears to result from collection being filtered by project name while persistence and DORA enrichment remain scoped only by the shared board:

  1. Jira raw-data parameters and collector state are identified by (connectionId, boardId) and do not include projectName or the rendered Extra JQL.
  2. Domain membership is stored as board_issues(board_id, issue_id).
  3. Each DevLake project maps to the same domain board through project_mapping.
  4. ConvertIssuesToIncidents selects incident-classified issues through project_mapping -> board_issues -> issues, without applying the project's Extra JQL or another project-specific issue predicate.

As a result, issues collected by one project can be treated as incidents of another project when both projects share the same Jira connection and board.

Relevant code:

What do you expect to happen

When Extra JQL is evaluated with {{.ProjectName}}, the resulting issue set should remain isolated for that DevLake project throughout collection, persistence, project mapping, and DORA enrichment.

An issue excluded by a project's rendered Extra JQL must not appear as an issue or incident for that project merely because another project collected it from the same Jira board.

How to reproduce

  1. Create one Jira connection and one Jira board containing recently updated bugs for at least two components, for example service-alpha and service-beta.
  2. Create two DevLake projects named service-alpha and service-beta.
  3. Map the same Jira connection and board to both projects.
  4. Assign both scopes the same scope configuration containing: 
    component = "{{.ProjectName}}"
  5. Configure a Jira issue type as the DevLake INCIDENT standard type (for example, Bug) so the DORA incident-conversion path is exercised.
  6. Run the pipeline for service-alpha, update a service-beta bug if needed to place it inside the next incremental window, and then run the pipeline for service-beta so issues for both components become associated with the shared board.
  7. Run service-alpha incrementally again, with no matching Jira issues updated during the incremental window.
  8. Confirm that collectIssues logs the correctly rendered component = "service-alpha" clause and that extractIssues/convertIssues process zero issues.
  9. Observe that ConvertIssuesToIncidents still processes incidents belonging to service-beta or other components associated with the shared board.

The following query illustrates the set currently used by DORA enrichment:

SELECT i.issue_key, i.component, bi.board_id
FROM issues i
JOIN board_issues bi ON bi.issue_id = i.id
JOIN project_mapping pm ON pm.row_id = bi.board_id
WHERE i.type = 'INCIDENT'
  AND pm.project_name = 'service-alpha'
  AND pm.table = 'boards';

Rows with components other than service-alpha are returned.

Anything else

This is not a template-rendering failure: the logs show that {{.ProjectName}} is rendered and included in Jira's effective JQL.

The available configuration workarounds are to create a distinct Jira board or a distinct DevLake Jira connection for every deployable unit. Both defeat much of the scalability benefit intended by #8955 and #9035.

A complete fix likely requires a project-specific logical scope for filtered Jira boards, rather than sharing collector state and board_issues solely by (connectionId, boardId). An end-to-end regression test should cover two DevLake projects using different rendered Extra JQL values against the same physical Jira board, followed by DORA incident conversion.

Version

v1.0.3-beta17@8fe26f4

Are you willing to submit PR?

  • Yes, I am willing to submit a PR.

Code of Conduct

Lenguaje dominante
Go
Estrellas
3.2k
Forks
819
Merge medio
2 d 8 h
PR fusionados (30 d)
50

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

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 apache/devlake

Todos los issues de apache/devlake

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.