[0xy]

What are some of the trickiest edge cases that you try to account for? I can only assume that this kind of system is enormously complicated, given the high expectations from users and the complexity of the underlying environments.

[sujayakar]

here's some of the greatest hits from memory:

1) when we upload a file, we first ask the server which blocks we need to upload. this allows us to deduplicate blocks with other files or previous revisions of files you have. I had written some code like...

  let blocks_needed: HashSet<BlockHash> = ...;
  let file_blocks: Vec<BlockHash> = ...;
  let to_upload: Vec<_> = file_blocks
    .into_iter()
    .filter(|b| blocks_needed.contains(b))   
    .enumerate();

  for (offset, block_hash) in to_upload {
    ...
  }

the bug here is that we're computing the offset into the file after filtering, so we'd be uploading incorrect contents to the server. we have protections elsewhere that would prevent file corruption, but finding this bug pre-commit with trinity was pretty awesome.

2) nontrivial interactions between different components in the system are hard to test manually and come for free with trinity. trinity will simulate cancelling file transfers, crashing the system, and even dropping the local databases (to simulate disk corruption). these are all hard enough to test in isolation, but knowing how to combine them is almost impossible. so, having "automated test generation" for these cases is really useful.

3) the "theory of trees" seems like it'd be pretty simple, but canopycheck has found some really interesting cases, especially around moves. when we started, we hadn't really thought about how to handle move cycles, concurrent moves that cross ancestor chains, ...