Change 202910 had a related patch set uploaded (by Yurik):
Refactored logging and a few other things per review

https://gerrit.wikimedia.org/r/202910

I have fixed most of the issues, but I am hesitant to migrate to HTTPError just yet - it provides a number of good features, but it also misses things I am using, like metrics counts and non-error logging. I will review it separately and possibly migrate to HTTPError later.

Change 202910 merged by Yurik:
Refactored logging and a few other things per review

https://gerrit.wikimedia.org/r/202910

In T95417#1191651, @Yurik wrote:

I have fixed most of the issues, but I am hesitant to migrate to HTTPError just yet - it provides a number of good features, but it also misses things I am using, like metrics counts and non-error logging. I will review it separately and possibly migrate to HTTPError later.

You are right, some general metrics logic in case of errors should exist. How about:

throw new HTTPError({
  message: 'blah blah',
  status: 500,
  metrics: {
    name: 'my.metric',
    func: 'endTiming',
    arg: startTime
  }
});

The expected result would be that when that error is caught, it would call endTiming('my.metric', startTime). Does that seem satisfactory?

What do you refer to when you say and non-error logging ?

I don't think bad user input should be logged as an error, but http code should be set to 4xx. Error is a bug in the service.
As for endTiming - a bit too verbose, for a large service you would have too many of them, obscuring the main logic... Not sure how to approach it yet, lets move it to a separate non-blocking discussion/service improvement.

Btw, re default protocol - the 'url' lib also treats colon as part of the protocol:

> require('url').parse('http://example.org').protocol
'http:'