Summary: Add a config option to log all outgoing HTTP requests.

I allow this RFC document to be modified and redistributed under the terms of the Apache-2.0 license, or the CC-BY-NC-SA 3.0 license, at your option.


This is a debugging aid, which is why it'll be off by default.

Guide-level explanation

If you set the BORS_LOG_OUTGOING environment variable, it will write every HTTP request to the log, making it easier to debug the GitHub API usage. For example

2020-08-03T07:00:15.168988+00:00 app[web.1]: 07:00:15.168 pid=<0.344.0> [info] GET -> 200 (194.823 ms)
2020-08-03T07:00:15.420605+00:00 app[web.1]: 07:00:15.420 pid=<0.344.0> [info] GET -> 200 (226.039 ms)
2020-08-03T07:00:15.621675+00:00 app[web.1]: 07:00:15.621 pid=<0.344.0> [info] GET -> 200 (200.326 ms)
2020-08-03T07:00:16.079808+00:00 app[web.1]: 07:00:16.079 pid=<0.344.0> [info] GET -> 200 (457.674 ms)
2020-08-03T07:00:16.286852+00:00 app[web.1]: 07:00:16.286 pid=<0.344.0> [info] GET -> 200 (206.264 ms)
2020-08-03T07:00:16.468819+00:00 app[web.1]: 07:00:16.467 pid=<0.344.0> [info] GET -> 200 (180.530 ms)
2020-08-03T07:00:16.468828+00:00 app[web.1]: 07:00:16.467 pid=<0.547.0> [info] Checking code owners
2020-08-03T07:00:16.667539+00:00 app[web.1]: 07:00:16.666 pid=<0.344.0> [info] GET -> 200 (198.168 ms)
2020-08-03T07:00:16.687920+00:00 app[web.1]: 07:00:16.686 pid=<0.547.0> [info] CODEOWNERS file %BorsNG.CodeOwners{patterns: [%BorsNG.FilePattern{approvers: ["@organisationjetteauloin/dummy"], file_pattern: "*"}]}

Reference-level explanation

The BORS_LOG_OUTGOING environment variable will activate the Tesla.Middleware.Logger plug-in.


It's probably not going to be used that much, though the ones that do use it will love it.

Rationale and alternatives

  • This could be turned on by default, instead of requiring a config option, but it's not likely to be used much in the production instances, because it's very noisy.
  • This could be done using a different method than the Elixir logger, but maybe metrics gathering should be a separate matter anyway.

Prior art

This is based on Tesla's existing features. We're just exposing it to the user.

Unresolved questions

Do we want something this ad-hoc? Or would we rather come up with more of an all-encompassing plan?

Future possibilities

Collecting metrics on API calls could allow us to detect things that go wrong, even in production setups where "just log and read everything" isn't much of an option.

See also

Implementation status

  • in progress