Commit Graph

3 Commits

Author SHA1 Message Date
Thomas Orozco
066cdcfb3d mononoke/unbundle_replay: also report recorded duration
Summary: This will make it easier to compare performance.

Differential Revision: D20674164

fbshipit-source-id: eb1a037b0b060c373c1e87635f52dd228f728c89
2020-03-30 06:25:07 -07:00
Thomas Orozco
d18cd74f7d mononoke/unbundle_replay: ignore entries with conflicts
Summary:
pushrebase_errmsg is NULL when we have conflicts, but we still shouldn't replay
the entry (because it'll fail, with conflicts). Let's exclude those.

Reviewed By: StanislavGlebik

Differential Revision: D20668304

fbshipit-source-id: a058bb466e0a8a53ec81e41db7ba138d6aedf3f9
2020-03-30 06:25:06 -07:00
Thomas Orozco
3804f1ca16 mononoke: introduce unbundle_replay
Summary:
This adds a unbundle_replay Rust binary. Conceptually, this is similar to the
old unbundle replay Python script we used to have, but there are a few
important differences:

- It runs fully in-process, as opposed to pushing to a Mononoke host.
- It will validate that the pushrebase being produced is consistent with what
  is expected before moving the bookmark.
- It can find sources to replay from the bookmarks update log (which is
  convenient for testing).

Basically, this is to writes and to the old unbundle replay mechanism what
Fastreplay is to reads and to the traffic replay script.

There is still a bit of work to do here, notably:

- Make it possible to run this in a loop to ingest updates iteratively.
- Run hooks.
- Log to Scuba!
- Add the necessary hooks (notably globalrevs)
- Set up pushrebase flags.

I would also like to see if we can disable the presence cache here, which would
let us also use this as a framework for benchmarking work on push performance,
if / when we need that.

Reviewed By: StanislavGlebik

Differential Revision: D20603306

fbshipit-source-id: 187c228832fc81bdd30f3288021bba12f5aca69c
2020-03-30 06:25:03 -07:00