Incorrect uptime showed for delegates during filtering

[mackuba]

Expected behaviour

When I scroll down the list of delegates, all delegates after place 101 have uptime shown as 0% - e.g. isabella at place 124. So when I filter the list by typing e.g. 'isab' in the search field, I'd expect to also see 0% uptime.

Actual behaviour

When filtering, isabella is shown as having 98.89% uptime.

Steps to reproduce

It's pretty random, sometimes it shows as 0% and sometimes as 98.89%. I think the rule is that if you don't scroll down the list and just start filtering, the delegates beyond 100 aren't loaded yet, and then isabella is shown with 98.89%. But if you first scroll down the list to load the places 100-200, and then scroll up and start filtering, the place 124 is already loaded, so it's shown with 0% uptime.

(v. 1.2.0)

[slaweet]

This is a bug in Lisk core API. The two API calls return different data.

https://node08.lisk.io/api/delegates/?offset=123&limit=1 (note that this link might change if rank of isabella changes)

{
"success": true,
"delegates": [
{
"username": "isabella",
"address": "12668885769632475474L",
"publicKey": "968ba2fa993ea9dc27ed740da0daf49eddd740dbd7cb1cb4fc5db3a20baf341b",
"vote": "498595604370475",
"producedblocks": 17931,
"missedblocks": 202,
"rate": 124,
"rank": 124,
"approval": 4.36,
"productivity": 0
}
],
"totalCount": 1452
}

https://node08.lisk.io/api/delegates/search?offset=0&limit=100&q=isabel

{
"success": true,
"delegates": [
{
"rank": 124,
"username": "isabella",
"address": "12668885769632475474L",
"publicKey": "968ba2fa993ea9dc27ed740da0daf49eddd740dbd7cb1cb4fc5db3a20baf341b",
"vote": "498595604370475",
"producedblocks": 17931,
"missedblocks": 202,
"approval": 4.36,
"productivity": 98.89,
"voters_cnt": 658,
"register_timestamp": 10850
}
]
}

[slaweet]

Reported in Lisk Core as LiskArchive/lisk-sdk#917
Closing here.