EDIFACT export scheduling doesn't support work in the cluster and after restart docker container

Overview

Before running scheduled task(job) there is check, that module is registered for the Okapi tenant.
Tenant information need to define DB schema for storing information about Job and etc.
In the post tenant API controller specific user (data-export-system-user) is created for running scheduled export tasks.
Also Okapi headers, system user, tenant information are stored in memory in a FolioExecutionContext.

Registration is happened in the Post Tenant controller, which invoked by POST request
"okapiprotocol://okapiurl:okapiport/_/proxy/tenants/xokapitenant/modules".

When a problem is discovered :

Case 1:

One instance of the mod-data-export-spring is deployed and registered. Schedulers work and no problem.
After some time instance crashed(no matter why) and Kubernetes(manually) restarts docker container.
Container restarted and no need to register modules, because version is not changed. As result Post Tenant controller was not invoked and flag in memory "registered" in the FolioExecutionContextHelper is "false".
Also no information about "system user" is stored in memory.
Finally job was not started by schedule.

Case 2:

Two or more instance of the mod-data-export-spring are deployed and registered. Schedulers work and no problem.
After some time one of the instance crashed(no matter why) and Kubernetes(manually) restarts docker container.
Container restarted and no need to register modules, because version is not changed. As result Post Tenant controller was not invoked and flag in memory "registered" in the FolioExecutionContextHelper is "false".
Also no information about "system user" is stored in memory.
Finally job was not started by schedule.

Question : How to understand which tenant or module version a particular deployed instance of the module belongs to?
Answer : from Mark Johnson
I think there are two parts to your question.
Please do let me know if I’ve misunderstood your question. I think I might have, especially for the tenant part.
Which tenant does a particular deployed instance of a module belongs to?
Instances of a module do not belong to any specific tenant.
All tenants in the same instance of FOLIO share all of the module instances.
For example, if a module version is enabled for 5 tenants, all requests for those tenants will be spread across all of the instances of that module version.

Which module version a particular deployed instance of the module belongs to?
There may not be a good way to do this.
Some modules might implement an endpoint that provides this kind of information. I don’t know if either RMB or FOLIO Spring Base do this by default. It could be worth FOLIO having a standard for such things.
Otherwise it will likely depend upon how the module is packaged and deployed.
For example, if it is a java module and running natively (against the JVM) then the jar might be named after the module version. If it is a docker image, the image might be named after the module version.

Workaround

If only one instance is used, then It is necessary to deploy and register a new version of the module using the same artifacts (docker container/image or fat Jar)

Approach

Open issues:

1. Scheduling happened by specific user : System user.
System user is initialized only in scope of PostTenant API (org.folio.des.controller.FolioTenantController).
This is API never called after container restarting or adding new instances of the mod-data-export-spring
2. Also looks like there is no easy way to define for which tenants particular instance is enabled.

Suggested approaches

1. To identify to which tenant instance is available looks like possible to use Okapi APIs, but for that need to define instance Id. After that will be possible to retrieve system users and instantiate org.folio.des.config.FolioExecutionContextHelper
To achieve that implementing ApplicationListener for WebServerInitializedEvent can allow read port and url of the instance and using this info define instance Id and after list of tenants.

Acceptance criteria

Scheduler works after restarting module without registering.