Fails with 'Broken pipe'

[gersmann]

Setup this action using a default config of:

    - uses: jordemort/action-pyright@v1
      with:
        github_token: ${{ secrets.GITHUB_TOKEN }} # You need this
        reporter: github-pr-review

This gives me this output when running the action:

  Traceback (most recent call last):
    File "/home/runner/work/_actions/jordemort/action-pyright/v1/pyright_to_rdjson.py", line 52, in <module>
      print(pyright_to_rdjson(sys.stdin))
  BrokenPipeError: [Errno 32] Broken pipe
  Error: Process completed with exit code 1.

Do you have any clue as to what could be going on here?

[jordemort]

Hm, it looks like sys.stdin is getting closed on the Python script somehow. I don't have any ideas off the top of my head as to why, but I'll poke around.

[jordemort]

Is there any output in the log before that?

[gersmann]

sure:

reviewdog: this is not PullRequest build.
  No configuration file found.
  pyproject.toml file found at /home/runner/work/app/app.
  Loading pyproject.toml file at /home/runner/work/app/app/pyproject.toml
  No include entries specified; assuming /home/runner/work/app/app
  stubPath /home/runner/work/app/app/typings is not a valid directory.
  Searching for source files
  Found 8375 source files
  Traceback (most recent call last):
    File "/home/runner/work/_actions/jordemort/action-pyright/v1/pyright_to_rdjson.py", line [52](https://github.com/parcelLab/app/runs/5552493101?check_suite_focus=true#step:10:52), in <module>
      print(pyright_to_rdjson(sys.stdin))
  BrokenPipeError: [Errno 32] Broken pipe
  Error: Process completed with exit code 1.

[jordemort]

I've got some changes over here that will hopefully make it easier to spot what's going wrong: https://github.com/jordemort/action-pyright/pull/21

Could you switch to uses: jordemort/action-pyright@broken-pipe and let me know how it does?

[gersmann]

Output appears properly, about 12.000 lines of JSON (there are currently 600 validation errors in the project).

Broken pipe output is gone, just exit code 1.

          },
          {
              "file": "/home/runner/work/app/app/status/lib/parser_report.py",
              "severity": "error",
              "message": "Operator \"|=\" not supported for types \"dict[str, Tuple[str, int]]\" and \"dict[str, Tuple[str, int]]\"\n  Operator \"|\" not supported for types \"dict[str, Tuple[str, int]]\" and \"dict[str, Tuple[str, int]]\"",
              "range": {
                  "start": {
                      "line": 107,
                      "character": 8
                  },
                  "end": {
                      "line": 107,
                      "character": 42
                  }
              },
              "rule": "reportGeneralTypeIssues"
          }
      ],
      "summary": {
          "filesAnalyzed": 1411,
          "errorCount": 634,
          "warningCount": 33,
          "informationCount": 0,
          "timeInSec": 17.543
      }
  }
  Error: Process completed with exit code 1.

[jordemort]

Does the broken-pipe version then run successfully and report (at least some of) the errors, does it still die with a BrokenPipeError afterwards, or does it fail in a different way now?

I don't think it's going to be able to make 600 comments succesfully; I'm pretty sure GitHub has a rate-limit / cap somewhere that will stop it before it gets through all that.

(edit: sorry for the accidental mention, random stranger)

[gersmann]

It terminates with process completed with exit code 1 right after dumping the json, so I guess pyright exists with exit code 1, but I have not set fail_on_error and the default is false.

Regarding 600 comments, reviewdog would only comment on added lines, right?

[gersmann]

Wondering if this could be the issue:

set -euo pipefail

Pyright seems to return exit code 1 in case there are errors in my local testing. Shouldn't that error code be ignored?

[jordemort]

Regarding 600 comments, reviewdog would only comment on added lines, right?

Ah yes, you're right.

Pyright seems to return exit code 1 in case there are errors in my local testing. Shouldn't that error code be ignored?

You're also right about that, I spotted the same thing. Could you give the broken-pipe version one more try? I think it should be all fixed up now.

[gersmann]

It works, nice 👍

[jordemort]

Thanks for your help sorting this out! I just cut a new release tag that includes the fixes, let me know if you run into any other problems.