-
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: Enable Logging functionality to both new and old Log Tables #657
feat: Enable Logging functionality to both new and old Log Tables #657
Conversation
removed useless test
…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
…om/near/queryapi into 641-introduce-provisioning-of-logs
async writeLog (logEntry: LogEntry, logEntries: LogEntry[], functionName: string): Promise<any> { | ||
logEntries.push(logEntry); | ||
const { level, blockHeight, message } = logEntry; | ||
if (blockHeight) { |
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 do we only call the old logging method if there is a blockHeight
? Shouldn't we always call it?
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.
Sorry, I should have made a comment here. I only added the if statement as a way of type asserting that bh exists. This is because the new log table allows for an optional 'bh' parameter, whereas the old method requires it. So when we call the writeLog and pass it an optional BH from LogEntry
and attempt to call the old writeLogOld we just type assert it with an if statement.
One possible solution is to keep the current code as is, or alternatively, use a type assertion equivalent for the syntax. Another option is to backtrack the old 'writeLog' method and make the 'bh' parameter optional, but I don't think this is worth doing if we plan on removing the old methods. in the next PR
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.
There's some confusion in your implementation about writeLog and writeLogOld. We ahve two separate functions. Are you trying to have writeLog also call writeLogOld? If so, writeLog should add to the log entries array and then call writeLogOld. And then we call writeLogs function on IndexerMeta at the end.
Or, if they're supposed to be separate, writeLog should not call writeLogOld. What's your intended implementation? The end result should be that ALL logs are added to the log entries array, and also calling writeLogOld. And then at the end, we run indexerMeta.writeLogs(THE LOGS ARRAY).
So, pick one:
A. writeLog adds to array, then calls writeLogOld
B. We only have writeLogOld and adding to logEntries.
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 confused about this comment here -.
The method writeLog's goal is to append a logEntry into logEntries[] and then call writeLogOld.
within direct block scope of runFunction we have access to both simultaneous promise array and logEntries array as they are declared locally.
Here we just push any log entries to an array for both to later be called in the finally so we do not use the writeLog method at all.
We start using writeLog in the other functional context - buildContext and buildDatabaseContext, originally they were just calling the old writeLog method-> now renamed to writeLogOld. This function has not changed besides the naming and its purpose is to run a graphQLQuery.
In the current code now we just added a param logEntries to both buildContext and buildDatabaseContext every time we want to write a log as the previous code want we just run it through the new writeLog method which does two things:
- appends a log entry to the logEntries array to later be resolved in the finally block of runFunctions
- call the writeLogOld to execute the graphQL query.
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.
I believe its already doing option A well here unless im missing something
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.
It looks odd as we explicitly call writeLogOld and then do logEntries.push earlier up (e.g. in Provisioning), and do writeLog() itself later on (e.g. context logs). I suppose this is fine?
I would like better would be to have writeLog take in a logEntry, a blockheight, logEntries array, and simultaneous promises array. You can add logEntry to the logEntries array (It may or may not have a BH). Then, you can add to simultaneous promises the call to writeLog Old which takes attributes of logEntry along with the passed in block height. This would result in writeLog fully encapsulating all our behavior, allowing us to keep writeLog calls exactly where they were originally while keeping the behavior. We also don't need to worry as much about optional blockheights. This is what I would consider to be a fully implemented option A.
Maybe @morgsmccauley can chime in here if I'm going off the track.
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.
I understand where you are coming from. If this is permanent code I also believe that it would be great to pass in simultaneousPromises as a Param into buildcontext and builddatabasecontext methods and just push to the respective logEntries/simultaneous promises arrays. This way the functionality is strictly appending entries to be later resolved in the finally block in run functions. But then I thought since this is all temporary and the next PR on sprint would involve removing the hasura writes it did not make sense to continue.
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.
Agree that this is a bit convoluted as we have two implementations going on. I would say let's defer tidying/optimising while this is in flux, and we can clean up once we remove the old implementation.
} | ||
`); | ||
|
||
expect(provisioning_endpoints.length).toEqual(2); |
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.
{
"message": "Provisioning endpoint: starting"
},
{
"message": "Provisioning endpoint: successful"
}
} | ||
`); | ||
|
||
expect(running_function_enpoint.length).toEqual(2); |
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 run on 2 blocks
await indexer.execute(Block.fromStreamerMessage(block115185108 as any as StreamerMessage));
await indexer.execute(Block.fromStreamerMessage(block115185109 as any as StreamerMessage));
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.
1 minor comment. Pre-emptively approving on the basis that mine/@darunrs comments are resolved before merging :).
async writeLog (logEntry: LogEntry, logEntries: LogEntry[], functionName: string): Promise<any> { | ||
logEntries.push(logEntry); | ||
const { level, blockHeight, message } = logEntry; | ||
if (blockHeight) { |
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.
Agree that this is a bit convoluted as we have two implementations going on. I would say let's defer tidying/optimising while this is in flux, and we can clean up once we remove the old implementation.
runner/tests/integration.test.ts
Outdated
@@ -149,6 +148,37 @@ describe('Indexer integration', () => { | |||
`); | |||
|
|||
expect(logs.length).toEqual(4); | |||
|
|||
const { morgs_near_test___logs: _logs }: any = await graphqlClient.request(gql` |
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.
const { morgs_near_test___logs: _logs }: any = await graphqlClient.request(gql` | |
const { morgs_near_test___logs: logs }: any = await graphqlClient.request(gql` |
The prefix here is really necessary, it's only really important at the DB level
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.
I didn't use this naming due to the above code targeting indexer_log_entries
const { indexer_log_entries: logs }: any = await graphqlClient.request(gql
What I will do is rename indexer_log_entries: logs
to indexer_log_entries: old_logs
(Not the best name but easy to spot and remove next PR). This current variable can be called logs
as suggested and will remove old_logs as apart of the PR to remove hasura writes
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.
Mostly good. Some comments to address. Can be merged after resolving the below comments.
@@ -33,12 +32,11 @@ export default class IndexerMeta { | |||
const pgClient = pgClientInstance ?? new PgClient(databaseConnectionParameters); | |||
|
|||
this.pgClient = pgClient; | |||
this.schemaName = indexerConfig.schemaName(); | |||
this.loggingLevel = indexerConfig.logLevel; | |||
this.indexerConfig = indexerConfig; |
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.
This is not necessary. Using private readonly will automatically expose indexerConfig to the class as a class variable.
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