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

Add GRPC API for querying the list of members for a given round #236

Conversation

poszu
Copy link
Contributor

@poszu poszu commented Jan 27, 2023

Closes #200.

  • the list of members is available after a round started executing,
  • the proof obtained via GetProof() GRPC doesn't contain a list of members anymore.

@poszu poszu linked an issue Jan 27, 2023 that may be closed by this pull request
@poszu poszu requested a review from fasmat January 27, 2023 13:10
Copy link
Member

@fasmat fasmat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should discuss the design of the ServiceDB and if we really need the synchronization that is currently built into it. I feel like this is not required since levelDB is already safe to be used concurrently.

What do you think?

service/db.go Show resolved Hide resolved
service/db.go Show resolved Hide resolved
service/service.go Show resolved Hide resolved
@poszu
Copy link
Contributor Author

poszu commented Jan 31, 2023

I think we should discuss the design of the ServiceDB and if we really need the synchronization that is currently built into it. I feel like this is not required since levelDB is already safe to be used concurrently.

What do you think?

Synchronization for safe concurrent use is absolutely not the point of this design. The point is to decouple the service generating proofs from the consumers of these proofs (and round data). In this design, the Service simply produces round data and proofs. It has no knowledge about what happens to them afterward.

IMO it greatly simplifies testing as a consumer is now completely decoupled from the producer. They are connected with a channel only. Take a look at the unit tests. They don't need a mock for the hypothetical "database interface". It avoids creating untestable monsters like the atxBuilder in go-spacemesh where UTs are a mock hell.

@poszu poszu requested a review from fasmat February 6, 2023 08:42
@poszu poszu marked this pull request as draft June 26, 2023 21:44
@poszu poszu closed this Aug 28, 2023
@fasmat fasmat deleted the 200-add-rpc-api-for-querying-the-list-of-members-for-a-given-round branch September 15, 2023 11:06
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 this pull request may close these issues.

Add RPC API for querying the list of members for a given round.
2 participants