-
Notifications
You must be signed in to change notification settings - Fork 3
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
feat: Introduce provisioning of Logs Table for new and existing users #643
Conversation
…omnearqueryapipull608' of https://github.com/near/queryapi into 641-introduce-provisioning-of-logs
…omnearqueryapipull608' of https://github.com/near/queryapi into 641-introduce-provisioning-of-logs
…omnearqueryapipull608' into 641-introduce-provisioning-of-logs
} | ||
} | ||
return allMutations; | ||
} | ||
|
||
// async getDatabaseConnectionParams(hasuraRoleName: string): Promise<DatabaseConnectionParameters> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed with @morgsmccauley a method used for integration test to point to the proper port and host.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh is this like a stop gap solution? I'm wondering what the problem is here and if we can modify the function/class to support both use cases somehow.
…om/near/queryapi into 641-introduce-provisioning-of-logs
PR introduces provisioning for new users. With Morgans PR #636 that has also been merged from main into this PR and uncommented out we also provision existing user's log table conditionally.
|
@@ -955,8 +965,9 @@ CREATE TABLE | |||
getDatabaseConnectionParameters: jest.fn().mockReturnValue(genericDbCredentials), | |||
fetchUserApiProvisioningStatus: jest.fn().mockReturnValue(true), | |||
provisionUserApi: jest.fn(), | |||
provisionLogsIfNeeded: jest.fn(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@morgsmccauley I added a few mocks in the test cases for the #636 pass test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you run this locally as well? Something like:
- Create indexer with old code.
- Run indexer with new code and confirm logs table provisioned correctly
- Create brand new indexer and confirm logs table provisioned correctly
- Ran both of those indexers with logs and verified logs appeared in both
If so, can approve.
this.database_connection_parameters ??= await this.deps.provisioner.getDatabaseConnectionParameters(hasuraRoleName) as DatabaseConnectionParameters; | ||
// this.indexer_logger ??= new IndexerLogger(functionName, this.indexer_behavior.log_level, this.database_connection_parameters); | ||
// this.database_connection_parameters = await this.getDatabaseConnectionParams(hasuraRoleName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is there a get db conn params function owned by Indexer in addition to the one in provisioner?
} | ||
} | ||
return allMutations; | ||
} | ||
|
||
// async getDatabaseConnectionParams(hasuraRoleName: string): Promise<DatabaseConnectionParameters> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh is this like a stop gap solution? I'm wondering what the problem is here and if we can modify the function/class to support both use cases somehow.
@@ -463,13 +492,12 @@ export default class Indexer { | |||
|
|||
// async writeLog (logEntry: LogEntry, logEntries: LogEntry[], functionName: string): Promise<any> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to pass in functionName here btw. We can sue the class variable this.indexerConfig to get the function name or full name or whatever it is you need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see this PR. Are you ok if I just add a separate ticket for this for when that PR is merged to directly use indexerConfig.functionName
?
@@ -178,6 +180,18 @@ describe('Provisioner', () => { | |||
await expect(provisioner.provisionUserApi(accountId, functionName, databaseSchema)).rejects.toThrow('Failed to provision endpoint: Failed to add datasource: some error'); | |||
}); | |||
|
|||
it('throws an error when it fails to run sql to create indexer sql', async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Use either run indexer sql or create indexer tables. Not a mix of both. Same for the below unit test. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im a little confused - they are 2 separate test with 2 different error messages.
As oppose to calling provisioner.provisionUserApi im calling the methods directly and they both use executeSqlOnSchema to mock a reject error with different error messages.
provisioner.runIndexerSql
provisioner.runLogsSql
I ran locally in the following PR #657. In the following PR the base is this current one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, if it's all locally tested, then LGTM! Make sure to observe dev to confirm the provisioning works in dev.
Check GCP logs for errors, check Hasura to see if indexers are running, and spot check particular indexers like access_keys_v1 to ensure that's running.
Uncommented functionality so we actually start writing logs to new the Tables that have been provisioned in #643. Old logging implementation remains untouched as still functions (although it has been renamed from writeLog -> writeLogOld). We are writing to both log tables. ### 1. Provisioning and Logging (to both tables) for a new Indexer https://www.loom.com/share/3ad6d6ea3368412e8896340a74759ffb?sid=4d5379e8-5401-41bf-9e38-d0f8e8c4eca5 ### 2. Logging (to both tables) for a existing Indexer https://www.loom.com/share/4ba411f2bcb740e1842650f695ffb347?sid=253ced68-9d4c-459f-871b-b0a3ee00cd91 ### Provisioning and Logging new logs table for a existing Indexer (that does not have logs table) https://www.loom.com/share/2aa7c0cc882f4dbdb9e51fc2a9e9b7b9?sid=1aa511fe-3054-4d27-9996-2b9fddc44ed8
First few commits is from this branch #640. Created this branch based off the initial branch.
This PR intends to introduce the creation of the logs table by provisioning the logsSchema and the follow CRON jobs for new Users but does not use or writeLogs to the new logsTable itself.
If this is merged by itself new users will have unused log table but the provisioning will occur.
To provision existing users - #636