Comment 13 for bug 1796971

Okay, potential fix is here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dbwells/lp1796971_wait_for_call_number_copy_load

working/user/dbwells/lp1796971_wait_for_call_number_copy_load

This problem also seemed to result from the branch labeled for bug #1732761, which from my casual looking is rather mysterious, as I'm not seeing a record in LP as to when that branch got pushed. (It was not in the omnibus, as suggested on the bug.) *shrugs* To be clear, I only mention this for the possibility of reviewers digging deeper to avoid regressions.

Anyway, from the commit message!:

In cases where add a copy to a call number, we fetch the original call number via async, then attach the new copy to it. Before this commit, however, we were not waiting for the call number fetch promise to resolve, so the copy wasn't there to use for limiting the location load.

Since the async request is internal to a loop, one way out is to capture that promise, then make sure it resolves before loading the locations.

Please note I still consider myself a relative novice when it comes to JS promises. While this is far from the only way to resolve this bug, it seemed to me to be the simplest without upending even more of the structure.

Dan