Pagination cursors are accepted with a different sort order or filter
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
- 35/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- go
- Área
- api, backend-api-design
Línea de trabajo
Start by reading TestAPI_CursorOfAnotherQueryListsFromItsPosition from #1109 and compare its asserted behavior with the examples and affected endpoints listed here. The issue leaves open whether to document cursor parameter requirements or reject mismatched queries with a versioned cursor format. Confirm that decision before defining the change; done means the chosen behavior is consistently covered for the listed tenant, event, and attempt lists.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
A cursor from one list request can be sent with a different dir or different filters, and the API accepts it. The cursor holds only a position (timestamp and id), so the list continues from that position with the new parameters.
Example: take next from GET /api/v1/events?dir=desc, then request GET /api/v1/events?dir=asc&next=<that cursor>. The response is a 200 with the rows newer than the cursor, which the client has already seen.
GET /api/v1/tenants, GET /api/v1/events, GET /api/v1/attempts and GET /api/v1/tenants/:tenant_id/destinations/:destination_id/attempts all behave this way. The event and attempt lists do so on every log store.
Options:
- Keep it and document that a cursor is only valid with the parameters of the request that produced it.
- Reject it with a 400
invalid cursor. The cursor would have to carry a hash of the query parameters, which means a new cursor format version.
TestAPI_CursorOfAnotherQueryListsFromItsPosition (added in #1109) asserts the current behaviour on the event and attempt lists.
- Lenguaje dominante
- Go
- Estrellas
- 1.1k
- Forks
- 70
- Merge medio
- 1 d 18 h
- PR fusionados (30 d)
- 56
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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de hookdeck/outpost
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
hookdeck/outpost#1117 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
Los mantenedores suelen responder en 1 día
Todos los issues de hookdeck/outpost
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
area: watch bug priority: low
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
mariadb-operator/mariadb-operator#1962 ·
Los mantenedores suelen responder en 1 día
-
bug good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
eugenioenko/ttt#919 · 1 comentario ·
Los mantenedores suelen responder en 1 día