Safe Network Dev Update - October 1, 2020

Thank you @Warren I hope I have or could live up to that. Humbling to see this kind of thing being said. For sure Safe is way too important for us all and that makes perceverance easy, plus many advances in tech helps too, just look at Marks recent work with wasm to have cross platform/paradigm apps. Truly amazing, we don’t stand on the shoulders of giants here, we are, as a community, acting like an organism where we invent, innovate, test, critique and most of all build and move forward. I try my best, like so many.

Intersting in house we see the launch closer than ever and with much more confidence in the tech and testing. That means we are a bit more probing and debating with each other as well as frustration and even close to anger, but collectively the team have never been stronger. I think the community mirror this as well. Some have left maidsafe and the community and did so with anger and a wee bit of seeing me as a monstor/silly/wrong or similar, even those folk though on launch will be so happy.

All in all though, we just need to get it done and we will.

21 Likes

Very well put @Warren, I agree with every word and it’s lovely to hear those thoughts expressed in words. I’m sure many of us are here because we see these qualities and abilities, but sometimes it’s important to say things out loud.

I’ve said before that very early on it was reading how David responded on Reddit to probing questions, and then reading his metaquestions blog, aslong with the quality of his technical expertise which singled out this project for me.

What you have outlined is I think why I’m still here, still putting hours in every week (yet feeling like I’m doing my own thing, and only doing what I want to do) because of David’s tenacity and ability to solve any issue that gets in the way, and do so while bringing the core team and a solid community along with him. I’ve no idea how he is able to do all of this.

Of course people leave, and of course some do so with anger or disappointment, but almost all have still remained supportive of this project because of the values which underly it and give David and all of us the energy to see it through. There’s nothing wrong with moving on, but for those who have been on the team, putting their own sweat, ideas and reputation on the line, it must be very hard to see the direction being changed away from something you toiled over and were committed to realising. I’m lucky to follow at a distance which makes it much easier to accept the twists and turns.

I doubt if I’d still be here without the inspirational qualities which David brings, not by charisma or oratory, but by being real, honest, and always focused on his vision to help people.

On leadership Warren, you are quite right to reject most of what is held up as leadership. But that doesn’t mean we don’t need leaders, what we need are people who show the way, and lead in the ways you’ve expressed. Well said, and thank you David for showing how it can be.

16 Likes

I think I have found the bug: in fn handle_commands of src/node/stage/mod.rs, generated subcommands are spawned and the function is exited. The root command is executed but not the subcommands that complete it. For example, in case of NodeApproval command the transition to new state (approved) is not yet executed, which means that the prefix is not set, which means that the node invariants may not pass verification depending on which task wins the race.

Correction is to ensure that every dependencies of the root command are executed before leaving the function, for example with this new code:

    pub async fn handle_commands(self: Arc<Self>, command: Command) -> Result<()> {
        let mut commands = self.handle_command(command).await?;
        while commands.len() > 0 {
            let mut sub_commands = vec![];
            for command in commands {
                sub_commands.extend(self.handle_command(command).await?);
            }
            commands = sub_commands;
        }

        Ok(())
    }

12 Likes

Hey @tfa, thanks for looking into this. We don’t wait for those subcommands to complete, but that doesn’t mean they won’t complete. They do, just asynchronously, in their own tasks. You will get notified about the node handling the NodeApproval message via the Connected event and at that point the node should be in the correct state. However, it seems we are firing the Connected event too soon (before the transition completes). So it seems there actually is a bug, just in a different place. Good catch, we’ll look into it.

EDIT: created an issue for it: Raise Event::Connected after transitioning to Approved · Issue #2204 · maidsafe/sn_routing · GitHub

10 Likes

the current model is that commands being processed in parallel, meanwhile your suggested solution is to process commands in sequence ?

1 Like

Yes, firing Connected event after the transition completes should also correct the problem in this specific case.

But you have to make sure that similar problems don’t happen with other subcommands executed in parallel. If unsure for any subcommands, maybe you could create two kinds of subcommands (the ones that can be executed in parallel without any risks and the others that don’t).

5 Likes