Release 2.1.0 #300
Merged
Release 2.1.0 #300
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In the previous version `required` and `nullable` annotations in `@ApiProperty` decorators were not accurate. Required fields frequently had `nullable` declarations and vice versa. It created difficulties for maintainers of external services that use Keys API under the hood because it was not possible to understand all the details of Keys API endpoint interfaces by just looking at the Swagger. Now all annotations are brought into compliance with actual endpoint interfaces that Keys API uses internally.
…er-docs fix: required field marks in Swagger annotations
The `start:prod` script in `package.json` worked incorrectly when the app was run locally without a container. Now it is fixed and the `start:prod` script is working fine when the app is running both locally and in a container. In the commit `f4baaf5985962409b1667cca452eb85b03c96961` from 12.09.23 the `benchmarks` folder was included in the output directory. This changed the directory structure in the `dist` folder. Before 12.09 the application build was situated directly in the `dist` folder (so, the `main.js` file was inside the `dist` directory). After that commit, the `dist` folder contains two subfolders: `src` and `benchmarks` and the application build is inside the nested `src` folder. When the app is run locally, there is no `main.js` file inside the `dist` folder, so, the `start:prod` script from `package.json` fails. This didn't break running application inside the container, because the Dockerfile copies only the `src` folder to the container and doesn't copy the `benchmark` folder. So, when the `yarn build` script prepares the application build, the folder structure inside the `dist` directory remains flat. The new `start:prod` script checks if the `main.js` file is directly in the `dist` folder (this is the case when the app is run in a container). If yes, it uses this file to run the app. If now (that means that the app is run locally), the script gets the `main.js` file from the nested `src` folder.
The `v1/modules/:module_id/keys` endpoint can accept only two query params (`used` and `operatorIndex`) that it uses to filter keys from the output. But previously public interface of this endpoint incorrectly stated that it also can accept the `moduleAddresses` param. It doesn't make sense, because module ID is specified in the `:module_id` URL param for this endpoint. Now the `moduleAddresses` search param has been removed from the public interface of the endpoint.
Replace the `KeysFilter` argument type in the `getModuleKeys()` method of the `SRModulesKeysService` with the type from `/common/entities`.
Remove unnecessary `moduleAddresses` query param from all endpoints where it was declared, but not used. These endpoints are: `/v1/modules/keys` `/v1/modules/:module_id/keys` `v1/modules/:module_id/operators/keys`
fix: migrate tests from goerli to holesky
The current e2e test setup has several issues. These changes are intended to fix some of them. 1. After starting the `e2e_pgdb` container with the database needs some time to complete initialization until it's ready to accept connections from the `e2e_keys_api` service. In my machine, the `e2e_keys_api` service always starts faster than the `e2e_pgdb` container completes its initialization. So, the `e2e_keys_api` service tries to connect to the DB in the `e2e_pgdb` container when it's not ready and always falls with a connection error. It looks better to wait until the database in the `e2e_pgdb` container completes its initialization and only after that start the `e2e_keys_api` container. To implement this, the new health checker has been added to the `docker-compose` file for e2e tests. The implemented approach is pretty the same as described here https://stackoverflow.com/questions/35069027/docker-wait-for-postgresql-to-be-running 2. The `--env-file=./.env` parameter in the `test:e2e` script in `package.json` is redundant, so, it has been removed. The docker-compose process can automatically recognize the .env file in the project root. 3. Hard-coded default DB name and credentials in the docker-compose file for the database container. As the database container with default setup works correctly only for the default database with default credentials, it doesn't make much sense to get these parameters from the `.env` file, because it's easy to misconfigure these parameters in the .env file for e2e tests. The idea is similar to the one introduced in this PR #267
Get rid of unnecessary `PickType` in the `KeyQuery` class definition. Now the `KeyQueryWithAddress` class extends the `KeyQuery` class.
Add default values to the database-related envs to the `docker-compose` file for e2e tests. These variables are needed for the test process and previously they were gotten from the `.env` file. Now they are hard-coded in the docker-compose file, so, an incorrect DB configuration variables in the `.env` file should not affect the successful run of e2e tests.
Rename scripts for e2e tests in `package.json` `test:e2e` -> `test:e2e:docker` `test:e2e:docker` -> `test:e2e` `test:e2e:docker:debug` -> `test:e2e:debug` It looks reasonable to keep the name `docker` only in the script that actually runs docker containers to run e2e tests inside them.
Vetted status for keys
rnmsslido
previously approved these changes
Sep 20, 2024
Optimized getLogs requests number, eth_call requests, fixed logs
eddort
approved these changes
Oct 1, 2024
rnmsslido
reviewed
Oct 1, 2024
rnmsslido
approved these changes
Oct 1, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.