This commit adds an endpoint to batch the sending of messages.
This is useful to simplify client logic when sending a batch of messages
and ensuring the correct order in the message stream.
It currently implements only what's needed, and naively return an error
if any of the messages fail.
We were not actually passing the topics in the request, therefore we
were using bloom filter for query, which resulted in long syncing times
for some users.
if an error is returned on the Send function, datasync will keep
retrying a message at each epoch. If the message cannot be sent (for
example is too large), then no messages will be sent until logout.
This commit fixes a bug on the mvds library where the nextEpoch would be
incorrectly summed to the retry time, resulting in messages not being
retried, or retried much less frequently the longer the app was running.
It also updates the retry timing to backoff exponentially at multiple of
30 seconds.
- Wallet service is not started on foreground event on status-go side
anymore, it leaves a client side opportunity to decide whether new
blocks should be watched.
- `watchNewBlocks` parameter is added to `StartWallet`.
- Some requests are removed/moved to the place where they are necessary.
In some cases no error is returned but the name is not verified.
Before this ENS names would get verified again every 30s.
This commit changes the logic so that if they fail to verify without
error they will still exponentially backoff.
When sending messages in quick succession, it might be that multiple
messages are batched together in datasync, resulting in a single large
payload.
This commit changes the behavior so that we can pass a max-message-size
and we split the message in batches before sending.
A more elegant way would be to split at the transport layer (i.e
waku/whisper), but that would be incompatible with older client.
We can still do that eventually to support larger messages.
Marketing was relying on mailserver entries for checking the time a
give peer spent on the app.
This was not accurate as the assumption was that a peer would "ping" a
mailserver every 15s, which is not the case, it only hit the mailserver
as it comes from an "offline" state.
This commit changes the log level of two entries so that we have
connect/disconnect time for a given peer, which should be enough to
calculate roughly the time a peer has been online if connected to our
fleet.
On logout happens sometimes that `PeersCount` is called when the server
has been removed.
This commit adds a guard to make sure that the server is not nil when
calling `PeersCount`.
We were checking for the wrong error kind when pulling messages from the
database, which resulted in the code not retrying to pull the message,
giving flaky tests / race condition (that's present in production as
well)
If one request failed, the whole batch would fail.
This caused issue as one of the contract is constantly returning an
error now, and essentially there was not way to fetch balance.
Also extend the timeout to 20s as we throw 165 request to Infura in one
go and it takes its time to reply to those, although it seems like we
should batch them on our side instead of sending them all cuncurrently.
Andrea Maria Piana
Roman Volosovskyi
andrey
Jonathan Rainville
flexsurfer
Volodymyr Kozieiev
Gheorghe Pinzaru
Jakub Sokołowski