probably won't be used

rebase

rebase

typo and small improvement in the test

In D6692#174126, @olasd wrote:

You seem to have dropped the CONTENT_BYTES_METRIC ?

Rebase on D6724 and adapt statsd tests to match new statsd probes

Add tests for expected statsd reports during a content replay session

Add a docstring in statsd fixture and update copyright dates in pytest_plugin.py

fix and swap args of 'assert' statements

In D6692#174129, @olasd wrote:

Could you make sure that this dashboard https://grafana.softwareheritage.org/d/d3l2oqXWz/s3-object-copy?orgId=1 is not affected (or that its functionality can be replaced easily?)

In D6692#174126, @olasd wrote:

You seem to have dropped the CONTENT_BYTES_METRIC ?

sorry I thought I had accepted it already :-)

In D6697#174282, @aeviso wrote:

When I did so with other tests your claim was that they were too difficult to follow and that tests should be as explicit as possible. These ones have a declarative function name for each case. What's the criteria after all?

Fine for me; these tests could be written as parametrized tests (https://docs.pytest.org/en/6.2.x/parametrize.html#parametrize-basics) but not a big deal.

Looks overall ok to me, but I miss a few "why?" here:

• the "why stop writing this file" should be in the commit message,
• why the need for SortOutputHandler attributes to become final?

typo

In D6644#172803, @vlorentz wrote:

since there is no guarantee the "expected" (considered invalid) revision will be consumed first

Really? Shouldn't the order be guaranteed by having only one partition per topic?

makes sense

rebase

rebase

rebase

rebase

fix docstring rst syntax

apply vlorentz' comments

rebase

Use a hardwritten list of accepted objects

used another approach, see D6571

apply vlorentz' comments/suggestions

fix test_cli

rebase and a few fixes

"fix" mypy

In D6570#171059, @douardda wrote:

In D6570#170758, @vlorentz wrote:

You checked on the whole journal, right?

not yet. The shouldn't be any left, but... I'll check as soon as I have credentials for the production kafka cluster.

Bump the dependency on swh-journal to 0.9

In D6570#170941, @olasd wrote:

While we're here, could you check whether the other fixers are really still needed too?

In D6570#170758, @vlorentz wrote:

You checked on the whole journal, right?

^x^s...

typo

Overall it looks very good to me. There is room for improvement, for sure, but let's put this to work and see how it performs.

Document a bit more the value_deserializer and add a test for it

asking for review even if tests are expected to fail because it depends on D6565 (in swh-journal)

In D6564#170522, @ardumont wrote:

why if i may ask?