Extract shared query parameter building for issue list operations

Abierto

#83 abierto el 28/2/2026 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad: 4/5
Tiempo estimado: 3-5 días
Aptitud para principiantes: 35/100

Tipo de issue: Refactorización
Claridad: Bastante claro
Estado de actividad: Estancado
Stack tecnológico: github
Área: api

Línea de trabajo

Compare the query parameter building in GetRepositoryIssues.apply() and Repository.get_issues(), including their recover blocks, conditionals, and push calls. Read nearby model convenience methods to assess whether a shared helper fits the broader pattern. Done means the duplicated logic is consolidated without changing issue-list query behavior.

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

Descripción

The query parameter building logic in GetRepositoryIssues.apply() and Repository.get_issues() is identical — same recover block, same conditionals, same push calls. If a new parameter is added, both sites must be updated in lockstep.

Repository.get_issues() can't delegate to GetRepositoryIssues.apply() because it has a template URL from the API response rather than owner/repo strings. It could potentially delegate differently, or the shared query param building could be extracted into a helper.

This is a pre-existing pattern in the codebase (other convenience methods on models also duplicate param building), so this may be worth addressing more broadly rather than just for issues.

Lenguaje dominante: Pony
Estrellas: 7
Forks: 2
Merge medio: 2 h 26 min
PR fusionados (30 d): 7