Comment 10 for bug 1271559

Sorry, stream of consciousness debugging incoming.

%services caches the allowed z39.50 service settings, and I'm assuming it sticks around between calls since the service keeps running?

It scopes the services to what the current auth user can access... but what happens when a different user with different z39.50 server scoping connects to the same open-ils.search service. And they don't have access to the same z39.50 services.

I suspect that is what I'm seeing, do_service_search is trying to get the host, port and db from an entry that doesn't exist for the user that created the %services cached info.

The sub do_search shorts out with a few 'or return undef;" calls if the host, port or db are not set.

So to trigger this, you need to have different users with different z39.50 services that they are allowed to use.

I think the initial calls to open-ils.search query_services cause the cached %services to be scoped to a particular user, since it calls fetch_service_defs($e) with an editor using the called auth token.

So an easy fix might be to not cache the %services in that case.

I bet this showed up when the use_perm for config.z3950_source was added.
https://gitlab.com/LARL/evergreen-larl/-/commit/6b900e1b5da091c09d0a4f668ca8618adfb4a260

One other thing I noticed, probably not actually a problem though, the do_class_search defines @services, which seems confusing when there is a global %services.

Josh