Xiangyi Zheng
Xiangyi Zheng
We now have our node logs in gcp, for example: [multichain-dev-1](https://console.cloud.google.com/logs/query;query=%2528resource.type%3D%22gce_instance%22%20AND%20resource.labels.instance_id%3D%224364092190727534926%22%2529%20OR%20%2528resource.type%3D%22global%22%20AND%20jsonPayload.instance.id%3D%224364092190727534926%22%2529;cursorTimestamp=2024-04-03T17:53:45.704390566Z;duration=PT1H?project=pagoda-discovery-platform-dev)
Seems the SEVERITY level only applies to log from GCP side, not logs from multichain service. I'm working with Kody on this
Looks like we can port severity level by using this library to set up the global logging subscriber: https://github.com/NAlexPear/tracing-stackdriver
not entirely sure. I'll move it back to backlog for now.
We've got mainnet dev on. The contract is `multichain-mpc-dev.near`. Have sent sign tx and succeeded. We are putting up a dashboard for mainnet dev and also will load test a...
are we referring to this? https://github.com/near/mpc-recovery/blob/6f46b0b648f9cf62cddd4c4eeea7742dbab59124/contract/src/lib.rs#L81
This might be related to https://github.com/near/mpc/pull/792 not included in rc3, where we wait a bit before checking the latest update timestamp of the indexer. What rc3 does is, it restart...
I'm trying to see if I can add an integration test where I mock stuck indexer by disabling the lake proxy then enabling it again. Will update
I realized this likely will be able to mock the situation where lake is not getting new blocks, and test whether the indexer is able to catch up by itself...
will take a look