Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Requests to _changes with descending=true ignore since #2733

Open
dianabarsan opened this issue Mar 30, 2020 · 1 comment
Open

Requests to _changes with descending=true ignore since #2733

dianabarsan opened this issue Mar 30, 2020 · 1 comment

Comments

@dianabarsan
Copy link

Description

When passing descending=true to _changes, CouchDB completely ignores the since parameter and always resolves with results as if since=now. It even ignores a malformed seq.

Steps to Reproduce

curl "http:https://<your_host>/<your_db>/_changes?limit=1&descending=true&since=NOT_A_SEQ"

Expected Behaviour

According to the documentation, descending means:

Return the change results in descending sequence order (most recent change first). Default is false.

No other interactions are documented. I would expect it to respect the since parameter.

Your Environment

  • CouchDB version used: 3.0, 2.3.1, 2.2, 2.1, 1.7 **
  • Operating system and version: Manjaro 19

** Couch 1.7 does return a badarg when passing a malformed since , but a correct since is ignored.

@dianabarsan dianabarsan changed the title Requests to _changes with decending=true ignore since Requests to _changes with descending=true ignore since Mar 30, 2020
@wohali
Copy link
Member

wohali commented Mar 30, 2020

Hi @dianabarsan , thanks for this.

I'm afraid to say that given you tested this all the way back to 1.7, this is probably a documentation error.

The code is pretty clear that the since token is ignored when descending (rev) is specified. I don't know if enhancing CouchDB to support this is possible, but I'll let others respond.

For now I'm changing this to an enhancement request. Once we've determined if this is possible or not, we can then decide if this goes forward in development, or instead turns into a "fix the docs" ticket instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants