From a retrieve request perspective, the simple-fetchers PR should make it relatively easy to track a specific retrieve request and for a developer to understand what went wrong with it.
However in terms of syncing, at the moment it is very difficult to understand if it is working correctly, or when we find that a chunk not found at max prox host in smoke tests, debug what went wrong.
I think one of the reasons for this is that syncing is an ongoing process, whereas retrieve requests have a specific entrypoint and are therefore easy to trace.
One thing that we could do it attach a trace to every SwarmSyncerServer for every peer and po. Then in a network of 100 nodes, where every node has 20 peers, that would result in 100 * 20 * 16 traces for syncing. We could attach a root span to the SwarmSyncerServer and call finish on it every 30sec, during which we append useful information (number of batches, chunks synced, cursors, etc.).
From a retrieve request perspective, the
simple-fetchersPR should make it relatively easy to track a specific retrieve request and for a developer to understand what went wrong with it.However in terms of syncing, at the moment it is very difficult to understand if it is working correctly, or when we find that a
chunk not found at max prox hostin smoke tests, debug what went wrong.I think one of the reasons for this is that syncing is an ongoing process, whereas retrieve requests have a specific entrypoint and are therefore easy to trace.
One thing that we could do it attach a trace to every
SwarmSyncerServerfor every peer and po. Then in a network of 100 nodes, where every node has 20 peers, that would result in100 * 20 * 16traces for syncing. We could attach a root span to theSwarmSyncerServerand callfinishon it every 30sec, during which we append useful information (number of batches, chunks synced, cursors, etc.).