Summary

We can proceed with changes to mod-users-bl, and those changes are very likely to be minimal (changes only to the module descriptor).

Methodology

Ran folio locally with Adam's folio-local-run shell script. Installed local postgres and modified the script to only install mod-users-bl in addition to mod-login, mod-configuration, mod-permissions, mod-authtoken, and mod-users. All other modules were moved out of the required section of mod-users-bl's module descriptor. This can be seen here: https://github.com/folio-org/mod-users-bl/blob/3bc214065de20fe564d8837305193e7e95bc6016/descriptors/ModuleDescriptor-template.json#L212.

In the tests, okapi ran in front of all modules, and handled starting each module's jar on a separate port.

Questions

1. Would okapi allow mod-users-bl to be registered with new optional dependencies without error?
2. How would mod-users-bl handle requests to endpoints (such as login) when certain modules, such as mod-inventory and its service points interface would be unavailable? Would extensive code changes be needed to make this work in a reasonable way?
3. What would happen with module permissions declared in the module descriptor such as inventory-storage.service-points-users.collection.get? Would these declared, yet non-existent permissions cause an error?

Okapi respects optional

Before moving items to optional, okapi failed to register mod-users-bl because of the unmet dependencies. After moving the previously required interfaces to optional, okapi allowed mod-users-bl to be installed and registered without error. Requests to mod-users-bl such as login and password-reset return successful responses.

How mod-users-bl handles non-existent interfaces

Mod-users-bl gracefully handles non-existent interfaces when they are called without any code changes. Its code has been written with this in mind. When an interface doesn't exist, such as for service points, okapi returns a 404 for the service points endpoint. The mod-users-bl code logs this 404, and continues with a completable future to the next API request in the chain of API requests that it makes in order to assemble the JSON object for its response. In the case of login, this JSON object is a CompositeUser instance. The final login response from mod-users-bl is a 201 with whatever parts of the CompositeUser it was able to assemble. But at no point does it fail.

Even if the code fails, not through a non-existent interface API failure, but through another exception, the chain of futures still continues. No one future in the chain is allowed to break the chain. This pattern is used throughout the BlUsersAPI.java class which is where all the endpoints are implemented.

Missing permissions are not a problem

In mod-users-bl's module descriptor many module permissions, such as inventory-storage.service-points-users.collection.get are declared for a given endpoint. These permissions do not cause problems when the module and therefore the permissions do not exist. This is because module permissions only come into scope (in mod-authtoken where these module permissions are checked) when a given module's endpoint is requested. When a module's endpoint doesn't exist, it is not ever requested. Instead the okapi responds with a 404 before the module's endpoint or mod-authtoken are ever called. And mod-users-bl gracefully handles these 404s.

Next steps

We're ready to move on to MODUSERBL-153 and get a PR going for the changes to the module descriptor. We may not need to make any additional changes to mod-users-bl to achieve our minimal platform goal.