move the code in get_journal_client

make the warning an exception, as suggested by vlorentz

In D6875#178755, @olasd wrote:

statsd.timing/statsd.timed do full histograms. Do we really want to keep bucketed counts for all of these values, or just a running total?

Gawd this is horrible! (not your fault!)

I'd feel more comfortable also if we have a good (aka documented and understood) reason for doing this.

vlorentz' comment + update copyright timestamps

closed by 259bf6fe1e3bacbcd2e91f8f3d55d49f5219892c

In T3134#76032, @vlorentz wrote:

wishlist: it would be nice ot be able to check the whole hash of a revision/release even when the author name/email are replaced by a hash. (eg. by making SWHIDv2 a tree hash)

I guess https://grafana.softwareheritage.org/d/d3l2oqXWz/s3-object-copy?orgId=1 is almost an answer to this task

LGTM (but see my comment)

Same comment as in D6712

It would really nice to have a better explanation of what this flag is added for and why. Why do we add complexity in the code for this? I know there are good reasons for that, but I cannot see them just reading the code or the commit message.

There is a small typo in the commit message (adn instead of and)

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