Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
In partnership with Protocol Labs, we’re excited to welcome builders from everywhere to APOLLO, your mission control to engage with the builder…
We’re excited to publically announce that Matic Network is partnering with Gitcoin to launch the Build-n-Earn Program – assisting dApps t…
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
# Overview / Motivation
Forwarding messages to protocols after shutdown might make the protocols assume there's a critical error. we don't want the protocols to handle it. we want to make sure no messages will be passed after shutdown started.
# The Task
Shut down swarm gracefully, don't allow protocols to send and receive messages after shutdown has started
# Implementation Notes
Have a look at `Shutdown` in `swarm.go`
Add a barrier to sending and processing flow in `SendMessageImpl`
Also after swarm has shut down don't pass messages in `ProcessDirectProtocolMessage`
the protocols should be aware that a shutdown has started once their messages channel is closed.
# Time Estimation
# Contribution Guidelines
Important: Issue assignment to developers will be by the order of their application and proficiency level according to the tasks complexity. We will not assign tasks to developers who have'nt introduced themselves on our Gitter [dev channel](https://gitter.im/spacemesh-os/Lobby)
1. Introduce yourself on go-spacemesh [dev chat channel](https://gitter.im/spacemesh-os/Lobby) - ask our team any question you may have about this task
2. Fork branch `develop` to your own repo and work in your repo
3. You must document all methods, enums and types with [godoc comments](https://blog.golang.org/godoc-documenting-go-code)
4. You must write go unit tests for all types and methods when submitting a component, and integration tests if you submit a feature
5. When ready for code review, submit a PR from your repo back to branch `develop`
6. Attach relevant issue to PR