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

feat: Enable Logging functionality to both new and old Log Tables #657

Merged

Conversation

Kevin101Zhang
Copy link
Contributor

@Kevin101Zhang Kevin101Zhang commented Apr 10, 2024

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

Kevin101Zhang and others added 30 commits April 4, 2024 18:09
removed useless test
…omnearqueryapipull608' into 641-introduce-provisioning-of-logs
@Kevin101Zhang Kevin101Zhang marked this pull request as ready for review April 10, 2024 22:51
@Kevin101Zhang Kevin101Zhang requested a review from a team as a code owner April 10, 2024 22:51
runner/src/indexer/indexer.ts Outdated Show resolved Hide resolved
async writeLog (logEntry: LogEntry, logEntries: LogEntry[], functionName: string): Promise<any> {
logEntries.push(logEntry);
const { level, blockHeight, message } = logEntry;
if (blockHeight) {
Copy link
Collaborator

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?

Copy link
Contributor Author

@Kevin101Zhang Kevin101Zhang Apr 12, 2024

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

Copy link
Collaborator

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.

Copy link
Contributor Author

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:

  1. appends a log entry to the logEntries array to later be resolved in the finally block of runFunctions
  2. call the writeLogOld to execute the graphQL query.

Copy link
Contributor Author

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

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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/src/indexer/indexer.test.ts Outdated Show resolved Hide resolved
}
`);

expect(provisioning_endpoints.length).toEqual(2);
Copy link
Contributor Author

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);
Copy link
Contributor Author

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));

Copy link
Collaborator

@morgsmccauley morgsmccauley left a 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) {
Copy link
Collaborator

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.

@@ -149,6 +148,37 @@ describe('Indexer integration', () => {
`);

expect(logs.length).toEqual(4);

const { morgs_near_test___logs: _logs }: any = await graphqlClient.request(gql`
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
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

Copy link
Contributor Author

@Kevin101Zhang Kevin101Zhang Apr 16, 2024

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

Copy link
Collaborator

@darunrs darunrs left a 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.

runner/src/indexer-meta/indexer-meta.test.ts Outdated Show resolved Hide resolved
runner/src/indexer-meta/indexer-meta.ts Outdated Show resolved Hide resolved
runner/src/indexer/indexer.ts Show resolved Hide resolved
runner/src/indexer/indexer.ts Outdated Show resolved Hide resolved
@Kevin101Zhang Kevin101Zhang merged commit e23d4c1 into main Apr 16, 2024
3 checks passed
@Kevin101Zhang Kevin101Zhang deleted the 650-release-logs-to-production-both-old-and-new-way branch April 16, 2024 18:55
@@ -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;
Copy link
Collaborator

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.

@Kevin101Zhang Kevin101Zhang changed the title Enable Logging functionality to both new and old Log Tables feat: Enable Logging functionality to both new and old Log Tables Jul 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Release Logs to Production (both old and new way)
3 participants