Sorting applies pagination before @cascade

What version of Dgraph are you using?

Dgraph Version
Dgraph version   : v21.03.1
Dgraph codename  : rocket-1
Dgraph SHA-256   : a00b73d583a720aa787171e43b4cb4dbbf75b38e522f66c9943ab2f0263007fe
Commit SHA-1     : ea1cb5f35
Commit timestamp : 2021-06-17 20:38:11 +0530
Branch           : HEAD
Go version       : go1.16.2
jemalloc enabled : true

Have you tried reproducing the issue with the latest release?


What is the hardware spec (RAM, OS)?

12 alpha @ 16c 32GiB ram on k8s.

Steps to reproduce the issue (command/config used to run Dgraph).

(EG: contrived schema and query to demonstrate issue, I dont actually want to do this specifically)

Imagine database state with 100,000 Persons. Simple query to retrieve those that live in Toronto can use @cascade to remove results that do not have an edge to the city node named Toronto.

Imagine 99,000 people of the 100,000 live somewhere else. So, this should grab the first 100 people that live in Toronto, sorted by name:

  a(func: type("Person"), first: 100, orderasc: name) @cascade(city) {
    name, xid
    city @filter(eq(,"Toronto"))

But, @cascade removes the pagination from first: until after the graph has been formed. That would be fine in this case, but orderasc, orderdesc put on their own pagination of 1000 if no other pagination is found.

Since cascade removes pagination, applyOrderAndPagination() in query.go sees a first: 0 and applies its own first: 1000 in ProcessGraph(), well before the final pagination from cascade is applied in ProcessQuery()

Expected behaviour and actual result.

Pagination should be consistent even if using sort and cascade, but it is not.


Any acknowledgement of this bug please?

Thanks @iluminae for reporting the bug. We’ll let you know once this is fixed.


Thank you @ahsan, I’m also tracking this as it prevents some key sorting operations on our cloud. Would a fix become directly available on Dgraph cloud or what do those release cycles look like? Thank you!

1 Like