Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serve API per each NodeID configured / known poets #6174

Open
Tracked by #328
ConvallariaMaj opened this issue Jul 21, 2024 · 2 comments · May be fixed by #6266
Open
Tracked by #328

Serve API per each NodeID configured / known poets #6174

ConvallariaMaj opened this issue Jul 21, 2024 · 2 comments · May be fixed by #6266
Assignees

Comments

@ConvallariaMaj
Copy link
Contributor

ConvallariaMaj commented Jul 21, 2024

per each POST identity configured / known poets (with some warning if they are missmatched)

@ConvallariaMaj ConvallariaMaj self-assigned this Jul 21, 2024
@ConvallariaMaj ConvallariaMaj changed the title per each POST identity configured / known poets (with some warning if they are missmatched) Serve per each POST identity configured / known poets Jul 21, 2024
@fasmat fasmat changed the title Serve per each POST identity configured / known poets Serve per each NodeID configured / known poets Jul 22, 2024
@ConvallariaMaj ConvallariaMaj changed the title Serve per each NodeID configured / known poets Serve API per each NodeID configured / known poets Jul 23, 2024
@pigmej pigmej transferred this issue from spacemeshos/pm Jul 23, 2024
@pigmej
Copy link
Member

pigmej commented Jul 23, 2024

So, we need an endpoint that returns PER IDENTITY:

  • which poets did It register into successfully (200 ok from the poet)
  • which poets it failed to register into (i.e., 429 for the registrations and ran out of time before the round started, etc.)
  • which poets it has no idea about (i.e., added to the config just now but not found in the DB)

That will allow users to understand what's the situation with the poets

@fasmat
Copy link
Member

fasmat commented Jul 23, 2024

That means failed registrations also need to be persisted into the local DB in a way that it makes clear which registrations are valid and which failed. This can probably be easiest achieved by leaving the RoundID field empty and setting the RoundEnd time to what it would have been according to the configuration of the node. When fetching the proofs from PoETs an additional check is needed such that when no RoundID is available it doesn't actually try to query the PoET for the proof.

When returning the current state of the identities if there are any registrations in the DB it should list the registrations with the following information (gathered from DB and config):

  • URL of the PoET the challenge was submitted to
  • End of the PoET round (when the node will fetch the proof)
  • Status
    • Registered: PoET is in config and registration was successful
    • Failed registration: PoET is in config and registration failed
    • Residual registration: PoET was registered to, but is not in config <- could indicate needed intervention by user
    • No registration: PoET is in config but was never registered to <- user added PoET to configuration after current round already started

This info should in my opinion only be returned if the identity is currently waiting to fetch proofs from PoET, otherwise the current state of the identity should be returned instead:

  • waiting to submit challenge to PoET
  • creating PoST proof / publishing ATX
  • creating initial PoST
  • waiting for state ATX Synced (which is a pre-requisite for the other states)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants