Mateusz Kudela authored 1 year ago and Bartek Wrona committed 1 year ago

When one node is starting from snapshot it has to have same config as
node which dumped snapshot. When plugins were changed using different
nodes and starting one from snapshot was impossible.

Mateusz Żebrak authored 2 years ago and Bartek Wrona committed 2 years ago

Related issue: #11

Related issue: #19

Related issue: #11

Piotr Batko authored 2 years ago and Bartek Wrona committed 2 years ago

Previously when node was preparing replay and copying block log file, it does
not care about block log name. If block log was named bad_block_log, then it
was copied with that name to SomeNode/blockchain directory. But it caused
problem, because node requires to have block log with name "block_log".

Now this name is enforced. During copying, destination file name is always set
to valid "block_log" name.

It allows to replay from renamed block log with syntax:
```
node.run(replay_from="/path/to/block_logs/block_log_5m")  # Note custom block log name
```

Piotr Batko authored 2 years ago and Bartek Wrona committed 2 years ago

It covers real use case, where users pregenerate block log for tests and then
copies it to selected directory.

Piotr Batko authored 2 years ago and Bartek Wrona committed 2 years ago

At the first version of block log implementation in TestTools, when block log object was
created, user had to decide how artifacts will be treated during copying.

Few commits ago there was added possibility, to override way of copying artifacts just in
time of copying (with `block_log.copy_to(destination, artifacts="always")`).

It turned out, that there is no need to specify it during block log creation in any use
case. Block log objects are used in following use cases:
1) to replay a node from given block log -- in this case node have to include artifacts if
   are provided (it's policy named "optional"),
2) to perform copy of block log generated by node under -- then users wants only block
   logs, without artifacts, and might be even suprised if artifacts would be copied
   together (it's policy named "exclude").

So in this commit:
- way of specifing how artifacts should be copied is disabled in BlockLog's initializer
- by default artifacts are not copied (by default are "excluded") to simplify use case #2
- in Node.run method, when block log is used for replaying node, artifacts are copied
  if provided, and it's ok, if are missing (it's policy named "optional") -- use case #1

Piotr Batko authored 2 years ago and Bartek Wrona committed 2 years ago

There was a bug, that first block_log file was copied, and then existing of
artifacts file was checked. If artifacts were missing, then error was raised,
but part of block log was already copied.

Now copying procedure ensures, that files to copy exists and copying will
pass without problems.

Piotr Batko authored 2 years ago and Bartek Wrona committed 2 years ago

Before:
- artifacts were either:
  - required (were copied with block log, when were missing warning were emitted), or
  - excluded (were always not copied, even if existed).

Now:
- artifacts can be:
  - required (as above, but when are missing raises exception instead of warning),
  - optional (copied when exist; missing artifacts is acceptable, is not treated as error),
  - excluded (same as above).