neicnordic / localega-deploy-swarm Goto Github PK

Describe the bug
The proxy service has a circular dependency.

To Reproduce
running the integration tests reproduces the problem.

Expected behavior
In uio-bmi/localega-tsd-proxy#42 spring-boot-starter-parent was upgraded from 2.3.5.RELEASE to 2.6.2 which does not allow circular referencing.

Screenshots
| The dependencies of some of the beans in the application context form a cycle:
|
| ┌─────┐
| | localEGATSDProxyApplication
| ↑ ↓
| | org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration$EnableWebMvcConfiguration
| ↑ ↓
| | org.springframework.security.config.annotation.web.configuration.OAuth2ClientConfiguration$OAuth2ClientWebMvcSecurityConfiguration
| └─────┘
|
|
| Action:
|
| Relying upon circular references is discouraged and they are prohibited by default. Update your application to remove the dependency cycle between beans. As a last resort, it may be possible to break the cycle automatically by setting spring.main.allow-circular-references to ***.

Is your feature request related to a problem? Please describe.
Update naming and comments in the test code to make the test code more readable/understandable.

Describe the solution you'd like
See description below

Additional context
Need to improve the naming of the methods in the test code and description of what the step is performing as comments:

upload() -> generates a random file and uploads it towards the REST API in the proxy service.
Needs an ELIXIR AAI like token to be able to upload data through this REST API
The Proxy service sends the upload message to CEGA RMQ

Wait() -> during this wait the CEGA should have time to receive and read the upload message at their end (we can probably not complete a submission and send a ingest message back before they have properly parsed the upload message internally!

ingest() -> Could be that it is impersonating CEGA and posting the ingest message back to us on behalf of CEGA. Yes: see below further down: in short - upload message is correctly sent above, but this ingest() step is impersonating the action of the user clicking “complete, I’m done with entering meta-data in this submission” in the submission portal!!!! By sending the ingest messages manually from the CEGA RMQ!

Wait() -> Is it actually here the ingest, verify and finalize microservices is doing their work? Yes. Including sending a completed message to CEGA and receiving the AccessionID message back.

verify() -> Check the state of the DB after finalize has the proper row with information for a fully ingested file (after finalize micorservice, including the StableID=FileAccessionNo)
Should be renamed to something like check_file_is_ingested_ok_after_finalize()

At this point nothing more will happen before we trigger the next step.

map() -> impersonates CEGA and triggers the map microservice with a mapping type RMQ message, with a synthetic/artifical DatasetID (not coming from CEGA)

download() -> downloads the file using the StableID in two different ways unencrypted and encruypted, asserts in each case that the checksum matches original checksum of unencrypted