Replay-tool replays ops from op files generated by fluid-fetch tool. It generates snapshots with specified frequency.
Run from packages/tools/replay-tool:
node .\dist\replayTool.js [OPTIONS]
Run it without any arguments to get usage and argument description.
node .\dist\replayTool.js --filename messages.json --to 100 --snapfreq 20
It will replay the ops from 0 to 100 and will take a snapshot after every 20th op and will write it in Output directory.
The snapshots will just appear in the --outdir in current directory. Filenames for snapshot will be like Snapshot_last_op_50.json and so on.
The snapshot service will take snapshot for the individual data store in the container and then the snapshot of the whole state will be taken.
The snapshot for container will appear in --outdir/container and the snapshot for data store will appear in --outdir/dataStoreName/.
If you are invesigating document corruption bugs, please start with Fluid Debugger workflow. Using debugger, you can quickly isolate if the issue reproduces when playing ops (form seq #0, i.e. not using snapshots). If not all ops are available, you might need to start with some distant shapshot. If you repro the bug using ops, you can use debugger to isolate further where issue (which op) is.
If, however, bug does not reproduce when playing ops, it likely points to a fact that saving and loading snapshot (at some point in time) causes trouble, i.e. it's not preserving information and causes client starting from snapshot have different in-memory representation of document.
You can leverage replay tool to find such bugs. As you replay ops, use --snapfreq flag to specify how ofter to generate snapshots (you can start with once in 100 ops, and tune it down up to snapshot per each op - that's best in finding bugs, but might be too slow for big documents). Each time snapshot is generated (for a given reference op), two files are written out - snapshot.json & snapshot_2.json. The first file is result of snapshotting document. The second file is result of initializing new container with such snapshot (i.e. loading from snapshot) and generating another snapshot from that container (disabling optimizations around reusing existing content in storage), without processing any ops. The two files should be exactly the same! If they differ, that very likely points to a bug (and diff will point you where the bug is)! Occasionally we may need to change runtime to write out snapshots in predictable way (i.e. sort order matters to do efficient diffs, like order of data stores in snapshot, or order of blobs - these things do not matter to runtime, but matter a lot when doing diffing of two snapshots).