Do you guys sleep? I feel like I missed a lot here.
On the scratchpad forks, yes, the last fix from Anselme fixed the issue for me. I never saw this issue until the last round of updates where the network went flaky. Here is what I suspect is happening:
- I intend to make an update to an existing scratchpad, so I download it to get the current counter value, let’s call this version A
- I increment the counter, and push the updated scratchpad to the network, now version B
- I repeat this operation for a subsequent update, but due to the state of the network or just lack of time for the edit to propagate, I sometimes only get version A and its counter value again.
On a subsequent get, now there are 2 scratchpads with the same counter, hence the forked scratchpad error. In my scratchpad get function, I do this:
let scratchpad = match self.client.scratchpad_get(&scratchpad_address).await {
Ok(scratchpad) => scratchpad,
Err(e) => match e {
ScratchpadError::Fork(scratchpads) => Self::select_newest_scratchpad(scratchpads),
_ => return Err(Error::Scratchpad(Box::new(e))),
},
};
The 'select_newest_scratchpad
function looks at all of the returned scratchpads and compares the header, where I put a timestamp like this: #2025-07-20T01:53:13.629506885+00:00
Then I take the newest one and return that scratchpad.
That’s how I fixed it, but I think the root cause is that the counter value (in my case) is arbitrary and relative to the last update. If I used some other increment value based on real time, I don’t think I would ever encounter this issue.
I never saw this issue on local or alpha, everything ‘just works’ on both of those. For pointers, I sometimes will get an error, which I’m guessing could be a similar scenario, but unlike @happybeing, I don’t have any issues. In my case, the pointer address never changes, it always points to the same scratchpad. I’m only using the counter value to tell me when an update occured on the scratchpad so I can skip downloading it when updating the local search cache.