Pagination cursors are accepted with a different sort order or filter
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- go
- Domain
- api, backend-api-design
Research direction
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.
Written by the indexing model from the issue text.
Description
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.
- Dominant language
- Go
- Stars
- 1.1k
- Forks
- 70
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 56
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hookdeck/outpost
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 4/5 3-5 days Newbie friendliness 48/100
hookdeck/outpost#1117 · 1 comment · 1 reaction ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
All issues in hookdeck/outpost
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
limitlessprojects/Go-Hybrid#50 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
vinyldns/go-vinyldns#106 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
praetorian-inc/augustus#334 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
ClickHouse/clickhouse-go#2066 ·
Maintainers usually reply within 1 day