We implement a new `Element` trait which allows for more complex output
to be drawn, such as vertical and horizontal stacks.
We adapt `Table` to work within this system.
We refresh the output of `rad patch show` to use these new tools.
For display purposes in the web client, we add with this commit the
some needed properties to the revisions in the patch endpoint.
Signed-off-by: Sebastian Martinez <me@sebastinez.dev>
Make the documentation more realistic by using two peers, a maintainer
and a contributor, for the client examples. Define them as 'workflow'
examples, ordering them in their own directory to aid user navigation.
This change ensures that on `Subscribe`, we only relay the latest
announcement of each node, per announcement category.
Previously, we would relay all announcement, while only the last one
was relevant.
If there is an unexpected error, eg. `BrokenPipe` in the upload process
process of the worker, we may have more than four bytes to read from the
remote socket. This change ensures that we don't attempt to read more
into a buffer of size `4`.
For whatever reason, we weren't using the deserializer for message
decoding. This meant that if a message came in two pieces, it would
cause decoding problems, since the first piece would be discarded.
It's possible that the daemon or stream closes the git connection
without reading the final `done` packet. If this is the case, we
try to read it after either of the connections is closed.
This may potentially mitigate the issue where the node then receives
the `done` packet while in gossip mode, and disconnects the remote
for misbehavior.
Due to never removing peers from the peer map in the wire
protocol module, it was possible for there to be multiple
connected peers with the same Node ID. Some might be in a
"connected" state, while others might be "disconnected".
This caused a bug where a peer, although connected would
be considered disconnected by the wire module, because
when searching for a peer with that Node ID, the disconnected
one would return first.
To fix this, we make sure to remove peers from the map once
the connection is dropped.
It's not a good idea to have fallible operations run after `FetchOk`
is received, since there's no easy way to communicate the error
to the remote at that point. What would then happen is that the fetch
just "hangs", since nothing is there to cancel it.
Hence, we compute namespaces earlier in the process, and store the
namespaces in the session. If there is a failure, the fetch is
never initiated.
The Reaction type needs to ensure that the `char` stored for its value
meets certain requirements -- via its `new` constructor.
To ensure Reaction is always constructed correctly, the `pub` accessor
is removed, and the Deserialize implementation is implemented by hand
-- as opposed to using derive.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
If Ops::try_from fails in from_history then it means that some
operations failed to be parsed.
If this happens, then a warning should be logged so that these failure
cases can be more easily traced.
Signed-off-by: Fintan Halpenny <fintan.halpenny@gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
It was possible to trigger multiple connection attempts to the same
peer, since we didn't track connection attempts that hadn't yet
returned to the service via `Service::attempted`.
With this change, we add an extra `Initial` state to sessions, so
that redundant connections are not attempted when one is already under
way.
Alexis Sellier
Sebastian Martinez
Slack Coder
Erik Kundt
Rūdolfs Ošiņš
xphoniex
Adam Szkoda
Alexis Sellier
Fintan Halpenny