Fix/client caching#765
Conversation
patricios-space
force-pushed
the
fix/client-caching
branch
4 times, most recently
from
2ec1f90 to
18a4d34
Compare
jadepark-dev
left a comment
jadepark-dev
left a comment
There was a problem hiding this comment.
Nice test harness! I agree with the direction.
First I wasn't sure about removing NewLazyLoadCtx since it was introduced to handle unreachable RPC on startup, but IIRC we already had a case where CCIPProvider blocked the plugin start and fixed by feeding a clientProvider. So it seems reasonable to relying on GetClietnt.
Also I've read a bit more into NewLazyLoadCtx and figured we're missing a Reset implementation. However, it would be more heavy lifting if we wanted TTL-based invalidation in the shared util.
Left a few comments, let me know when you have follow-up tests
patricios-space
force-pushed
the
fix/client-caching
branch
from
18a4d34 to
efc9217
Compare
patricios-space
force-pushed
the
fix/client-caching
branch
3 times, most recently
from
670cde5 to
9b95972
Compare
patricios-space
requested review from
krebernisak,
ogtownsend and
vicentevieytes
patricios-space
force-pushed
the
fix/client-caching
branch
from
9b95972 to
e742561
Compare
patricios-space
force-pushed
the
fix/client-caching
branch
from
e742561 to
f3f14c6
Compare
patricios-space
force-pushed
the
fix/client-caching
branch
2 times, most recently
from
c0ff66a to
f3f14c6
Compare
…that it does not block service initialization
jadepark-dev
left a comment
jadepark-dev
left a comment
There was a problem hiding this comment.
Added comments, Can you utilize data we have? I'd suggest to aggregate error logs from live nodes to see where we are getting the not found errors most
| } | ||
|
|
||
| var resp tl.Serializable | ||
| // TBD do we need to call .WaitForBlock(shardBlock.SeqNo) here? |
There was a problem hiding this comment.
You might want to check the internal of
ton.GetShardBlockProof{
ID: shardBlock,
}
but unlikely it's fetching account state.
There was a problem hiding this comment.
I haven't found this error in production logs
Original: 197s Grouped: 115s Parallel: 80s
|
I wonder if we could add a linter check that |
|
Accidentally closed |
3 participants
TON LogPoller and TXM could permanently stall after node restart
No context timeout when calling CreateLiteserverConnectionPool / AddConnection
Once we create a client for LogPoller and TXM it never refreshes
If a RCP goes down, the LogPoller and TXM cannot recover
We should remove the commonutils.NewLazyLoadCtx as GetClient already has caching.
LogPoller is using a signed client when it shouldn’t
Only TXM needs a signed client.