Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typeorm updation #1606

Closed
wants to merge 35 commits into from
Closed

Typeorm updation #1606

wants to merge 35 commits into from

Conversation

RidhamShah
Copy link
Collaborator

@RidhamShah RidhamShah commented Jun 4, 2024

This PR covers below changes:

  1. Update typeORM and all related depreciated code to new code.
  2. Now, the export replica hostname would also be an array as a separate env variable TYPEORM_HOSTNAME_EXPORT_REPLICA and rest replicas (if any) would be in the TYPEORM_HOSTNAME_REPLICAS. For now you need to move the value in TYPEORM_HOSTNAME_REPLICAS to TYPEORM_HOSTNAME_EXPORT_REPLICA.
  3. We updated the typeormLoader file to have the mainDB connection use the 2nd read replica as slaves which will be automatically used for any read operation that uses the main DB connection by default. Only the export queries would use the export connection which will hit the 1st read replica. In case we dont have a 2nd read replica, all the reads apart from export queries would hit the main RDS instance.

VivekFitkariwala and others added 28 commits May 12, 2024 15:01
(cherry picked from commit 4e7a6ee)
@RidhamShah RidhamShah marked this pull request as ready for review June 30, 2024 09:47
@danoswaltCL
Copy link
Collaborator

Currently all of our CL client lib usage is on 5.0, which is fine right now, 5.1 is not required. When this code gets promoted, since still synced with dev, it will carry everything currently in dev also as 5.2.

5.2 shouldn't be required either. Are we sure that this 5.2 TypeOrm update version won't break compatibility with CL apps using 5.0? I ask because a change like this should not be merged in yet, that would break all of our clients on staging and we would need to get them to update their libraries / usage. Can we maybe cease pulling dev and "freeze" into branch this so we don't pull in accidental surprises? Then we can pip dev to like 5.3? @VivekFitkariwala @RidhamShah @bcb37

@@ -1014,7 +1014,7 @@ export class ExperimentClientController {
@Delete('clearDB')
public async clearDB(@Req() request: AppRequest): Promise<string> {
// if DEMO mode is enabled, then clear the database:
if (env.app.demo) {
if (!env.app.demo) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this change?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove. i have to assume someone was doing this in debugging and accidentally committed it, if this change snuck into prod, anyone with a token would be able to delete our database by doing DELETE /clearDB. It makes me nervous even having this endpoint exist in the first place for this exact reason.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code updated

return { userId: individual.userId, segment: segment.id };
});
await transactionalEntityManager.getRepository(IndividualForSegment).delete(usersToDelete as any);
// const usersToDelete = segmentDoc.individualForSegment.map((individual) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the commented code isn't needed anymore, let's get rid of it, we can see the old implementation in git history

@@ -22,6 +22,7 @@ LOG_OUTPUT=dev
#
TYPEORM_CONNECTION=postgres
TYPEORM_HOST=localhost
TYPEORM_HOSTNAME_EXPORT_REPLICA=[]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the separate new env var needed for the typeorm update? does it need to be an array if it's just one thing?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it was part of improvement we found while updating replica connection syntax during this PR. Its kept as an array for consistency with the other replica hostnames var. We can make it a string if you want.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, this complicates promoting this to production as it's an unexpected configuration change that I don't remember being talked about. @bcb37 @VivekFitkariwala what do you think

@danoswaltCL
Copy link
Collaborator

danoswaltCL commented Jul 12, 2024

Seeing these errors when doing /assign to a context with any experiments enrolling (not just group). I see same thing in local as when I deployed this branch into our staging environment.

{
"client_session_id": null,
"endpoint": "/v5/assign",
"level": "error",
"message": {
"className": "IndividualExclusionRepository",
"code": "42703",
"details": "Error in assignment",
"driverError": {
"code": "42703",
"file": "parse_relation.c",
"length": 126,
"line": "3648",
"name": "error",
"position": "282",
"routine": "errorMissingColumn",
"severity": "ERROR"
},
"file": "parse_relation.c",
"functionName": "findExcluded",
"length": 126,
"line": "3648",
"parameters": {
"experimentIds": [
"83ae5cc5-1e78-4c00-8306-20499058941e",
"abcd6602-f8c6-4779-adf6-127c16af8cd9",
"b39586e4-275d-435a-afda-6e9bbbb72ad9",
"c643eb90-046f-458e-8420-9d9495282ccb"
],
"userId": "locust12"
},
"position": "282",
"query": "SELECT "individualExclusion"."createdAt" AS "individualExclusion_createdAt", "individualExclusion"."updatedAt" AS "individualExclusion_updatedAt", "individualExclusion"."versionNumber" AS "individualExclusion_versionNumber", "individualExclusion"."id" AS "individualExclusion_id", "individualExclusion"."groupId" AS "individualExclusion_groupId", "individualExclusion"."exclusionCode" AS "individualExclusion_exclusionCode", "individualExclusion"."experimentId" AS "individualExclusion_experimentId", "individualExclusion"."userId" AS "individualExclusion_userId", "experiment"."createdAt" AS "experiment_createdAt", "experiment"."updatedAt" AS "experiment_updatedAt", "experiment"."versionNumber" AS "experiment_versionNumber", "experiment"."id" AS "experiment_id", "experiment"."name" AS "experiment_name", "experiment"."description" AS "experiment_description", "experiment"."context" AS "experiment_context", "experiment"."state" AS "experiment_state", "experiment"."startOn" AS "experiment_startOn", "experiment"."consistencyRule" AS "experiment_consistencyRule", "experiment"."assignmentUnit" AS "experiment_assignmentUnit", "experiment"."postExperimentRule" AS "experiment_postExperimentRule", "experiment"."enrollmentCompleteCondition" AS "experiment_enrollmentCompleteCondition", "experiment"."endOn" AS "experiment_endOn", "experiment"."revertTo" AS "experiment_revertTo", "experiment"."tags" AS "experiment_tags", "experiment"."group" AS "experiment_group", "experiment"."conditionOrder" AS "experiment_conditionOrder", "experiment"."assignmentAlgorithm" AS "experiment_assignmentAlgorithm", "experiment"."logging" AS "experiment_logging", "experiment"."filterMode" AS "experiment_filterMode", "experiment"."backendVersion" AS "experiment_backendVersion", "experiment"."type" AS "experiment_type", "experiment"."stratificationFactorStratificationFactorName" AS "experiment_stratificationFactorStratificationFactorName", "user"."createdAt" AS "user_createdAt", "user"."updatedAt" AS "user_updatedAt", "user"."versionNumber" AS "user_versionNumber", "user"."id" AS "user_id", "user"."group" AS "user_group", "user"."workingGroup" AS "user_workingGroup", "user"."originalUserId" AS "user_originalUserId" FROM "individual_exclusion" "individualExclusion" LEFT JOIN "experiment" "experiment" ON "experiment"."id"="individualExclusion"."experimentId" LEFT JOIN "experiment_user" "user" ON "user"."id"="individualExclusion"."userId" WHERE "individualExclusion"."id" IN ($1, $2, $3, $4)",
"routine": "errorMissingColumn",
"severity": "ERROR",
"type": "Error in the assignment algorithm"
},
"request_id": "8fb2d683-de24-45ba-9d55-5d95fe9fd842",
"request_method_type": "POST"
}
{
"client_session_id": null,
"endpoint": "/v5/assign",
"level": "error",
"message": {
"endPoint": "/api/v5/assign",
"message": "column individualExclusion.groupId does not exist",
"name": "QueryFailedError",
"request": {
"context": "assign-prog",
"userId": "locust12"
},
"type": "Error in the assignment algorithm"
},
"request_id": "8fb2d683-de24-45ba-9d55-5d95fe9fd842",
"request_method_type": "POST"
}

@@ -1014,7 +1014,7 @@ export class ExperimentClientController {
@Delete('clearDB')
public async clearDB(@Req() request: AppRequest): Promise<string> {
// if DEMO mode is enabled, then clear the database:
if (env.app.demo) {
if (!env.app.demo) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove. i have to assume someone was doing this in debugging and accidentally committed it, if this change snuck into prod, anyone with a token would be able to delete our database by doing DELETE /clearDB. It makes me nervous even having this endpoint exist in the first place for this exact reason.

@danoswaltCL
Copy link
Collaborator

Can someone please report out exactly what the breaking changes are in this code that we should be aware of? This branch will essentially be promoted directly to staging and then to prod as its own release apart from dev.

There are definitely some commits that exist in 5.1 that I recall being asked to not merge down into dev, please check that also.

@danoswaltCL danoswaltCL added the priority: high High priority issue label Jul 15, 2024
@danoswaltCL
Copy link
Collaborator

danoswaltCL commented Jul 16, 2024

Tested the changes in local and in staging with some quick running of locust tests just to get a sense of the API working, looks good no errors, times looked good also.

Here are my notes on things that need changed for deploying to production. Please help me to note other things to check with this update so we are sure prod's version (release/v5.1) is not going to break when we deploy this branch.

notes:
METRICS var will need to be modified in prod. In staging I removed the METRICS var in order to get it to run, I have not tested correctly the new format.

TYPEORM_HOSTNAME_EXPORT_REPLICA is a new var, what is the correct usage? Is does this replace the other replica array?

Please also notice this.

@bcb37 we should find an hour or so to swap in the db one more time and test it together

@ppratikcr7
Copy link
Collaborator

ppratikcr7 commented Jul 17, 2024

Tested the changes in local and in staging with some quick running of locust tests just to get a sense of the API working, looks good no errors, times looked good also.

Here are my notes on things that need changed for deploying to production. Please help me to note other things to check with this update so we are sure prod's version (release/v5.1) is not going to break when we deploy this branch.

notes: METRICS var will need to be modified in prod. In staging I removed the METRICS var in order to get it to run, I have not tested correctly the new format.

TYPEORM_HOSTNAME_EXPORT_REPLICA is a new var, what is the correct usage? Is does this replace the other replica array?

Please also notice this.

@bcb37 we should find an hour or so to swap in the db one more time and test it together

Yeah METRICS needs to be updated.

Now, the export replica hostname would also be an array as a separate env variable TYPEORM_HOSTNAME_EXPORT_REPLICA and rest replicas (if any) would be in the TYPEORM_HOSTNAME_REPLICAS. For now you need to move the value in TYPEORM_HOSTNAME_REPLICAS to TYPEORM_HOSTNAME_EXPORT_REPLICA.

Ridham has reverted that delete api change.

@danoswaltCL danoswaltCL dismissed their stale review July 17, 2024 17:59

updated

@ppratikcr7 ppratikcr7 marked this pull request as draft August 1, 2024 07:37
@ppratikcr7 ppratikcr7 closed this Aug 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: high High priority issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants