Work around some mgr:forward accounting/reporting bugs

[rousskov]

In modern code, FwdReplyCodes[0][i] is usually zero because n_tries is
usually at least one at logReplyStatus() call time. This leads to
mgr:forward report showing nothing but table heading (i.e. no stats)

Also improve try#N heading:data match by skipping FwdReplyCodes[0]
reporting (there is still no try#0 heading) and adding a previously
missing try#9 heading

[rousskov]

I do not like that this change hides (rare) try#0 counters, but it is probably better than reporting no counters at all.

A proper fix would require significant refactoring. It should be done, but I do not have the time for that right now.

Please see the following squid-users thread for context: https://lists.squid-cache.org/pipermail/squid-users/2024-December/027333.html

[rousskov]

This change has been confirmed as working by the bug reporter.

[kinkie]

ok to test

[rousskov]

squid-anubis added the M-waiting-staging-checks label 4 days ago

kinkie removed the M-waiting-staging-checks label 5 hours ago
squid-anubis added the M-waiting-staging-checks label 5 hours ago

kinkie removed the M-waiting-staging-checks label 5 minutes ago
squid-anubis added the M-waiting-staging-checks label 4 minutes ago

@kinkie, M-waiting-staging-checks label is managed by Anubis and is simply reflecting (Anubis interpretation of) PR state. Just removing that label from a live PR is unlikely to solve any problems -- in most cases, Anubis will simply restore the label when it gets a chance.

I did not check any details, but perhaps Anubis is waiting for more staging tests to start? Perhaps its configuration got out of sync with our set of tests again? Please let me know if you need my help with anything related to the above label changes.

[kinkie]

I'm trying to figure it out as we speak. I have disabled codeql and reduced the number of checks required, but Anubis' logs are on one side very verbose and on the other side very hard to parse if someone is not familiar with the code. I'm now trying to get Anubis to redo the staging checks to see if the configuration changes help. What is the best way to do it?

…

On Sun, Dec 29, 2024 at 7:58 PM Alex Rousskov ***@***.***> wrote: squid-anubis added the M-waiting-staging-checks label 4 days ago kinkie removed the M-waiting-staging-checks label 5 hours ago squid-anubis added the M-waiting-staging-checks label 5 hours ago kinkie removed the M-waiting-staging-checks label 5 minutes ago squid-anubis added the M-waiting-staging-checks label 4 minutes ago @kinkie <https://github.com/kinkie>, M-waiting-staging-checks label is managed by Anubis and is simply reflecting (Anubis interpretation of) PR state. Just removing that label from a live PR is unlikely to solve any problems -- in most cases, Anubis will simply restore the label when it gets a chance. I did not check any details, but perhaps Anubis is waiting for more staging tests to start? Perhaps its configuration got out of sync with our set of tests again? Please let me know if you need my help with anything related to the above label changes. — Reply to this email directly, view it on GitHub <#1969 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHPVDF3R3C4NZPYQ5ZOQGL2IBA3VAVCNFSM6AAAAABUDGBNY2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRUHAYTEOJSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Francesco

[kinkie]

OK to test

[rousskov]

I'm now trying to get Anubis to redo the staging checks ... What is the best way to do it?

Anubis does not do staging checks. GitHub (and Jenkins?) test a commit staged by Anubis.

To redo staging tests, consider these basic minimally-invasive options:

• Use GitHub (and Jenkins?) UI to restart any test for the existing staged commit.
• Change staged commit input (e.g., PR description) a bit to force Anubis to regenerate a staged commit.

I have now done the latter.

[rousskov]

I see no changes in staged commit checks performed for the last two staged commits; they both show 89 checks.

[kinkie]

• Use GitHub (and Jenkins?) UI to restart any test for the existing staged commit.

The problem here is that the CodeQL test is not even started, and I can see no way to make it work because somewhere somewhere it still expects to find it in default.yaml

• Change staged commit input (e.g., PR description) a bit to force Anubis to regenerate a staged commit.

I have now done the latter.

Thanks.

[rousskov]

The problem here is that the CodeQL test is not even started, and I can see no way to make it work because somewhere somewhere it still expects to find it in default.yaml

AFAICT, "the CodeQL test is not even started" is not a relevant problem: That problem existed for a long time. I first whined about it to you on Zulip in October 2024. PRs have been merging successfully while that problem was present, of course. I speculate that something broke CI (in relevant ways) during very recent attempts to land #1971. I have not investigated what happened.

[kinkie]

The problem here is that the CodeQL test is not even started, and I can see no way to make it work because somewhere somewhere it still expects to find it in default.yaml

AFAICT, "the CodeQL test is not even started" is not a relevant problem: That problem existed for a long time. I first whined about it to you on Zulip in October 2024. PRs have been merging successfully while that problem was present, of course. I speculate that something broke CI (in relevant ways) during very recent attempts to land #1971. I have not investigated what happened.

No, PR #1971 was my attempt to address CodeQL errors - see https://github.com/squid-cache/squid/pull/1969/checks?check_run_id=34801150013 . The error message can't be found online, but it seems to imply that some CodeQL configurations are left connected to the branch inside GitHub's systems; all I've been trying to do in the past couple of days has been to figure out how to remove that reference, restore it, or reset it. So far, unsuccessfully.

[rousskov]

AFAICT, despite starting with the word "No", your response does not contradict my observations and speculations.