post init rerun

[lrettig]

Describe the bug

My app lost its peer connections. I restarted it, and after I restarted it, it performed post initialization again (automatically, it didn't ask me to choose a directory again). It appears to have gotten a new node ID.

To Reproduce
Steps to reproduce the behavior:

1. Install 0.0.7 on windows
2. Init smeshing
3. Let node run overnight.
4. It loses peer connections.
5. Close the app and click Quit.
6. Restart the app.

Expected behavior
No need to init post again.

Desktop (please complete the following information):

• OS: Windows

Additional context

Here you can see the two ID folders in the allocated folder for post data:

Full logs here

[avive]

Please share url to access zipped logs - it is very hard to investigate these kind of issues w/o access to the full node logs...

[lrettig]

@avive there's a link to the logs at the bottom of my first post ;)

[avive]

Sorry I somehow missed it. Ignore my comment.

[avive]

This is a kind of bug that requires an initial investigation by looking at the log and deciding if it is likely an app issue or a go-spacemesh issue or both as it is not clear.

[lrettig]

Agree, it might be a go-spacemesh issue

[avive]

@antonlerner

[IlyaVi]

not related to app

[lrettig]

Instead of closing can we transfer this issue to go-spacemesh, if we're sure the issue is on that side? Unless an issue was already opened?

[avive]

We should. It is a potentially a serious issue. I suspect there's logic in go-spacemesh to re-create post with a new smesher id if there's some issue with the existing one as it intercepts the post setup flags passed to it when it starts as 'Please start mining'. It should remember if it has setup post in a previous session (was started or was completed), the smesher id used and report and error if it can't verify the post commitment. The new proposed smesher API assumes this kind of behavior to report issue back to client users so they can decide what to do - e.g. attempt to delete the old commitment and setup a new one. In general, this is also part of separating via the api the smeshing part (mining) and the post commitment management (setting up a commitment).

So, the node should not attempt to start smeshing unless it has a valid commitment setup and when it does it should use it. If user attempts to start the node via flags or api calls to smesh when commitment is not set - the operation should fail. Right now, the node attempts to handle the commitment automatically when it is asked to start smeshing and it hides the commitment status from the api. It should not do that once the new api is implemented.

[avive]

@noamnelke @moshababo FYI. I was not able to reproduce this on my nodes. There may be some condition that triggers this bug. Not sure how to progress on addressing this issue.

[noamnelke]

I think that there's no logic for not using an existing miner id. The miner id should be stored with the private key in the node's datadir. If it's not found a new identity is created. Maybe the datadir changed? @moshababo any other idea?

[brusherru]

Outdated.
Check out #823 and spacemeshos/go-spacemesh#2858