Currently, LookupResources walks the graph of the permission, starting at the subject and walking "upward" until it finds specific resource+permission pairs, for that subject. In the case of there being two (or more) paths to the same resource+permission, you can get duplicate results out of LR (and this is expected behavior, although we will work to document it further).
Unfortunately, if you have multiple caveated paths and multiple non-caveated, you'd see more than two results, some conditional and some not, in any order (unless using cursors).
The recommendation for LR remains to always do deduplication on the client side and to either always give full caveat context on LR calls where you expect to show results or to always do a followup CheckBulkPermission with the full context (which is a good idea for conditional results, regardless). Since duplicates are already a known limitation of cursored LR calls, it is expected that clients will either be okay showing duplicates or do this de-duplication themselves.
Making LookupResources group results by resource_object_id is not possible without the risk of requiring unbounded memory or the need to pass around extremely large state in cursors.
Creating this issue to track interest around doing the above.
Currently, LookupResources walks the graph of the permission, starting at the subject and walking "upward" until it finds specific
resource+permissionpairs, for that subject. In the case of there being two (or more) paths to the same resource+permission, you can get duplicate results out of LR (and this is expected behavior, although we will work to document it further).Unfortunately, if you have multiple caveated paths and multiple non-caveated, you'd see more than two results, some conditional and some not, in any order (unless using cursors).
The recommendation for LR remains to always do deduplication on the client side and to either always give full caveat context on LR calls where you expect to show results or to always do a followup CheckBulkPermission with the full context (which is a good idea for conditional results, regardless). Since duplicates are already a known limitation of cursored LR calls, it is expected that clients will either be okay showing duplicates or do this de-duplication themselves.
Making LookupResources group results by resource_object_id is not possible without the risk of requiring unbounded memory or the need to pass around extremely large state in cursors.
Creating this issue to track interest around doing the above.