cloudfoundry/cli

'X-Cf-Warnings' header should not print to stdout by default for `cf curl`

tcdowney opened this issue · 3 comments

tcdowney commented

Please fill out the issue checklist below and provide ALL the requested information.

  • I reviewed open and closed github issues that may be related to my problem.
  • I tried updating to the latest version of the CF CLI to see if it fixed my problem.
  • I attempted to run the command with CF_TRACE=1 to help debug the issue.
  • I am reporting a bug that others will be able to reproduce.

Describe the bug and the command you saw an issue with
In cloudfoundry/cloud_controller_ng#2227 we decided to set the X-Cf-Warnings header when one of the services backing the /v3/processes/:guid/stats endpoint has an error and we decide to return a partial response.

This is nice because the user will still get informed that something is not quite right by the cf cli, but otherwise continue to see other information about their process. Using the cf7 CLI it looks like this warning is usually printed to stderr, but for cf curl it is being printed to stdout and making the response difficult to parse.

What happened
When I use cf curl to hit an endpoint that sets the X-Cf-Warnings header the warning is printed to stdout and makes the output no longer JSON parseable. Example:

cf curl /v3/processes/e9c6facc-7c9b-4cf6-9a7f-e5a4c908157c/stats
{
   "resources": [
      {
         "type": "web",
         "index": 0,
         "state": "RUNNING",
         "host": "127.0.0.1",
         "uptime": 173624,
         "mem_quota": null,
         "disk_quota": null,
         "fds_quota": 16384,
         "isolation_segment": "placeholder",
         "details": null,
         "instance_ports": [
            {
               "external": 80,
               "internal": 8080,
               "external_tls_proxy_port": null,
               "internal_tls_proxy_port": null
            }
         ],
         "usage": {}
      }
   ]
}
Stats server temporarily unavailable.

Expected behavior
The X-Cf-Warnings header would either be printed to stderr or ignored and only displayed if the user requests it via the -i (Include response headers in the output) flag.

Exact Steps To Reproduce
Steps to reproduce the behavior; include the exact CLI commands and verbose output:

  1. Push an app
  2. bosh ssh doppler
  3. sudo su -
  4. monit stop log-cache
  5. cf curl /v3/apps/$(cf app MY_APP --guid)/processes to get the web process guid for the app
  6. cf curl /v3/processes/:guid/stats

Provide more context

  • Mac OS X 11.13 iTerm
  • cf version 7.2.0+be4a5ce2b.2020-12-10
  • Dev capi-release. Should be the next one after capi-release 1.109.0.

Related Issues and PRs

cf-gitbot commented

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/178006715

The labels on this github issue will be updated when the story is started.

hjcalderon10 commented

Hi!
We are currently reviewing this issue and found some insights:

  • The CLI prints every X-Cf-Warnings as a warning through the stdout. As shown
  • It is possible to print the X-Cf-Warnings as a stderr when the env CF_RAISE_ERROR_ON_WARNINGS is set. As shown

This is the expected behavior for the X-Cf-Warnings management.

cc @jdgonzaleza

  • 👍1
tcdowney commented

I see, I didn't realize it always went to stdout. Good to know about CF_RAISE_ERROR_ON_WARNINGS, thanks. 👍

  • 👍1