I see this is now listed as closed, which is fantastic - thanks so much! May I ask if this will appear in a Kiwi hotfix or will the fix first be available in Lotus?

 and all, mod-user-import belongs to Core Platform. I have reassigned. 

cc:  and

From SUPPORT SIG:  This ticket has been moved to Vega

Firstly, the Prokopovych team does not own this module. At the very least, I think it could be worth involving the folks that do in this conversation.

This topic was discussed in the TC channel on Slack.

There doesn't seem to be a conclusion to those conversations beyond asking developers to think about this stuff.

1. Set a limit for the search that's super-high and hope that it's high enough to get all entries and low enough that it does not crash anything. Obviously, this is super-easy to implement. It's also hack-y and may lead to more problems in the future.

I agree with all of the concerns here.

2. Examine the totalRecords field in the returned list of departments, and if it's higher than ten, do another call that sets the limit to that number so as to get them all. This will make the code more inefficient since it may have to do more than one call to the endpoint to get all records, and I've also heard that the counts in these result sets may not be reliable.

I wouldn't trust the total records count for this logic. Instead, fetch pages until an empty page is fetched.

This approach potentially makes the memory usage more manageable than a high arbitrary limit. We really don't have the tooling to make these decisions well in the technical space alone.

3. Rework or create a new endpoint in mod-users that will return all department records without needing a limiter. I believe Zak has already suggested this. Obviously, this is more work, and involves changing code in (potentially) two separate modules. If we are going to do this for departments, then we should also do it for other endpoints that are being queried, like patron groups, which makes this even more work.

I think raised that this approach is highly dependent upon there being a stable expectation for the number of departments in an organisation.

As usual, this is the kind of thing that we need both the product folks involved in (to figure out those expected department counts) and the technical folks (to have a consistent way of doing this across the project).

If time is a factor here (and it seems like it is) then I'd recommend fix #1, with us slating some issues to more permanently address this problem later.

I agree the easiest fix (and the one often chose in other areas) is the larger arbitrary limit.

Maybe we could add something that checks if the count of departments is the same as the limit and logs / includes a warning in the response that this likely means departments are missing due to how they are fetched.

As we don't own this module, we include them in the decision to defer a different solution.

, thanks! I think it was changed Juniper to Kiwi because the library we discovered this with is on Juniper and the issue is there. I was multitasking so much that I didn't even think to test Bugfest.