- App registrations and app updates now go through a check if peers received the specification message. Peers also have to send back the specifications message to prove correct communication was established. This check adds up to 10 seconds of additional time in registering/updating for message propagation but ensures sufficient amounts of nodes received and rebroadcasted the message which prevents loss of a crucial message
The scheme is changed from following way
1. store temporary message in temp message collection
2. broadcast message to peers (no waiting for broadcast to finish)
to following scheme
1. broadcast message to peers (fully wait for broadcast to finish)
2. Broadcast for request the same message from our peers (fully await for broadcast)
3. As peers begin to send us the message, message undergoes further validation and gets stored into temporary message collection
- General improvements in Flux communications
- Reconstruction of App Hashes collection - due to a bug, app hashes may have marked a message as received and stored even though that may not have been the case. Reconstruction happens on restart of Flux
- Add API with owner and fluxteam permissions to reconstruct app hashes collection
/apps/reconstructhashes - Temporary messages api call
/apps/temporarymessages/:hash?now accepts hash as filtering parameter - Permanent messages api call
/apps/permanentmessages/:hash?now accepts hash as filtering parameter - Various code improvements, error catching
- Add notification for message propagation to UI