This PR removes (options.limit >= maxRecordCount) from the conditional assignment of json.exceededTransferLimit. After some code review, I realized this check was not necessary and can actually break paging behavior of clients. The check is not necessary because:
option.limit is already set to maxRecordCount when the request doesn't arrive with a req.query.limit or a req.query.resultRecordCount (see here).
The option.limit is already used by the Winnow dependency to determine limitExceeded (see here). limitExceeded is passed back to FeatureServer and used in the check we are aiming to simplify.
There is no reason to check both metadata.limitExceeded && (options.limit >= maxRecordCount); if fact, doing so breaks the ability of resultRecordCount to properly set exceededTransferLimit to true which can break paging functionality of clients.
This PR removes
(options.limit >= maxRecordCount)from the conditional assignment ofjson.exceededTransferLimit. After some code review, I realized this check was not necessary and can actually break paging behavior of clients. The check is not necessary because:option.limitis already set tomaxRecordCountwhen the request doesn't arrive with areq.query.limitor areq.query.resultRecordCount(see here).The
option.limitis already used by the Winnow dependency to determinelimitExceeded(see here).limitExceededis passed back to FeatureServer and used in the check we are aiming to simplify.There is no reason to check both
metadata.limitExceeded && (options.limit >= maxRecordCount); if fact, doing so breaks the ability ofresultRecordCountto properly setexceededTransferLimittotruewhich can break paging functionality of clients.