Aha - that’s it. Thanks @danda
OK - that chimes with this error
but if I try
willie@gagarin:/tmp$ safe files get safe://cdn/css/southside.css
[00:00:00] [########################################] 236B/236B (2.84KB/s, 0s) Transfer
Done. Retrieved 1 files to .
then it works fine
I have contemplated extending
safe files get to work with immutabledata urls also, however the other subcommands of
safe files all work with FilesContainer data, so it breaks the paradigm a little. anyway, It might gain that capability in the future.
Success of command depends on which node sends the information last
This is most likely a limitation of the sans-parsec baby-fleming network. We’re already looking at a few things to be solving this without the need for a slow consensus step so hopefully will get it sorted in a fresh iteration.
We should get this noted and clarified on the latest baby-fleming network page’s known limitations. Thanks for diving in and the detail @tfa!
I understand this is the answer for the second problem. And what about the first problem? (objects not duplicated on new vaults)
As I understand it that’s likely the same issue. Only that vault having the key balance in the initial… We dont have inter-vault gossip enabled yet (and without parsec it’s not being shared in that fashion. Though not the person on this so not 100% sure TBH. @lionel.faber may be able to shed more light).
for the issues @tfa notes, there’s not much to be done at the mo in terms of testing. We’re working on some things to reenable consensus and gossip so will get sorted in another testnet iteration once we’ve that in. Thanks though @Southside!
Even without PARSEC, the objects (Data structs, balances etc.) should be present in all the vaults. I suspect that the vaults might not have formed a section correctly. Although looking at the commands that you have run, everything seems right.
Could you please confirm that in the vaults logs the routing table size is 7?
One more thing to look out for is the port number being used. I see that you have mentioned a port number for the genesis vault. Could you please check if the other vaults are using separate and different ports?
Yes, I confirm the routing table size is 7 and that the port numbers are all different. You can see them by scrolling the log excerpts in my post to the right:
Response from: V4(192.168.1.68:NNNNN).
Okay thanks. Is it possible that you might’ve sent the create account request before the other vaults were started?
Could you try creating a fresh account and see if the same issue persists?
Was there no way to just make PARSEC faster?
The procure is exactly as described in my post. Only at the last step I try to create an account (after all 7 vaults were created).
For each vault I waited for the right routing table size to appear, plus some margin until no messages are exchanged anymore.
So you are facing the same issue when creating fresh accounts as well?
If that’s the case then it’s definitely a bug.
Because once a section is setup, the client will declare an account successfully created only if it receives a success response from all the vaults.
Edit: The client only looks at the last response.
But on the other hand, if a 3 vaults return success and 4 return failure, then the client will return a failure but the account’s existence is inconsistent between vaults in the section and this is indeed a known limitation of the current testnet.
Yes, anytime I tried to create a new account. This was last Sunday. But now I have restarted a new network directly with 7 vaults which doesn’t exhibit this problem. And I don’t want to lose this configuration so I cannot make new tests.
You can see from the logs that the client always received one success response and 6 error responses.
If the success response was the last to be received then the command was successful.
If an error response was the last then the command failed.
Good to know!
Ah yes. Sorry my bad. The client just looks at the last response. I’ll edit my message
Would you like a fix to be implemented for this?
Client says Success if only all vaults return success? This might bring up some other inconsistencies but it’s definitely an improvement.
Ok, client only looking at the last response explains the second problem.
Once again what about the first problem? It shouldn’t have happened according to your remark:
In fact I would like more a fix for this one because if it is corrected in the first place, then the second problem won’t occur.
It may well be possible. But it seems if we don’t need to have strict order on some things then we can lighten the load of what we do need to parsec for (which should speed things up).
Agreed, good idea. Just spitballing here, but have you looked into whether the strict ordering in PARSEC could be relaxed ( as an option depending on use case)?
For example rather than saying ‘this sequence of individual events happened in order’ it would be ‘this sequence of event sets happened in order’.
An ‘event set’ would just be a bag/group of unique unordered events. Perhaps the move to larger and larger blockchain block size is a good analogy?