dhagrow commented :
We are currently experiencing an issue very much like this. We have a query that looks like this:
{
q(func: type(node)) @cascade {
~user.node @filter(eq(user.name, "dave")) {
~process.user @filter(gt(process.started_at, "2020-03-25T00:00:00")) {
count(uid)
process.started_at
}
}
}
}
Using that query, the earliest value for process.started_at in the results is 2020-03-26T17:04:22.98387Z, and we get 13 “process” nodes.
If the filter is set to 2020-03-26T17:05:00, the earliest value for process.started_at is 2020-03-26T17:06:01.320919Z, with 12 “process” nodes, which is correct (one node is filtered out).
However, if the filter is removed, the earliest value for process.started_at is 2020-03-25T15:57:05.245431Z, with 597 “process” nodes. That date is clearly greater than the date set by the original filter.
When using the filter, regardless of how far back we set the date, the first result is 2020-03-26T17:04:22.98387Z.
This is a scenario I’ve been able to reproduce just now. We first noticed this problem when a query would return some results (but not always all the expected results), and a few seconds later would return no results at all.
The only mild indication of anything wrong on the server end is this warning on 1 (of 6) alpha:
W0326 17:51:42.073138 1 draft.go:1014] Raft.Ready took too long to process: Timer Total: 655ms. Breakdown: [{sync 655ms} {disk 0s} {proposals 0s} {advance 0s}] Num entries:
1. MustSync: true