Jobs stuck in queues for a couple days (adding ESLint additional_dependencies)

[Samuel-Therrien-Beslogic]

Hi! I was working on this https://github.com/BesLogic/releaf-canopeum/pull/175 , iteratively working through which dependencies I had to explicitly specify, which dependencies I could omit, and figuring out what I had to trim and make optional from our shared configs to fit under the 250MiB restriction (thanks npm/node_modules).

Everything was going well until suddenly the pre-commit job got stuck in queue. I thought this could be some caching issue, so I opened a new PR, on a new branch, with re-written git history (squash) here https://github.com/BesLogic/releaf-canopeum/pull/177 w/o success.

I searched this repo for similar issues, I found

• https://github.com/pre-commit-ci/issues/issues/181 but it was working before, and I've been removing dependencies as I was making them optional and testing which ones take how much space, I also have much less dependencies than in that example
• https://github.com/pre-commit-ci/issues/issues/220 Whilst https://www.githubstatus.com/incidents/88003ngctf1z recently popped up, it did the day after I started experiencing issues and is now resolved
• https://github.com/pre-commit-ci/issues/issues/62 I did get 1 timeout. But that issue was a temporary issue on pre-commit's side, nothing to do on my side other than report. What I'm getting here is different anyway.

Here's the repo jobs: https://results.[pre-commit.ci](https://results.pre-commit.ci/repo/github/771018559)/repo/github/771018559 I have no information on why the jobs could be stuck in queue. Is one of my dependency problematic? Is there an issue on pre-commit.ci's side. Did I hit some sort of throttling? (I'd be fine with that if I just hit some weekly/monthly quota). None of my other repos are having issues.

Here's my config atm:

# You can run this locally with `pre-commit run [--all]`
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace
        args: [--markdown-linebreak-ext=md]
      - id: end-of-file-fixer
      - id: mixed-line-ending
        args: [--fix=lf]
      - id: check-yaml
      - id: check-toml
      - id: check-merge-conflict
      - id: check-case-conflict

  # You can run this locally with `ruff check --fix || ruff format`
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.5.2 # must match canopeum_backend/requirements-dev.txt
    hooks:
      # Run the linter.
      - id: ruff
        args: [--fix]
      # Run the formatter.
      - id: ruff-format

  # You can run this locally with `npm run lint:fix`
  - repo: https://github.com/pre-commit/mirrors-eslint
    rev: v8.56.0
    hooks:
      - id: eslint
        args: [--fix, --quiet]
        files: \.[jt]sx?$ # *.js, *.jsx, *.ts and *.tsx
        types: [file]
        additional_dependencies: [
            # Keep these in sync with canopeum_frontend/package.json
            "eslint-config-beslogic@2.4.5",
            "eslint-plugin-jsx-a11y@6.8.0",
            "eslint-plugin-react@7.34.1",
            "eslint-plugin-react-hooks@4.6.0",
            "eslint-plugin-react-prefer-function-component@3.3.0",
            "eslint-plugin-react-refresh@0.4.5",
            # NOTE: Optional, removing to reduce bundle size: exceeds tier max size 250MiB
            # "eslint-plugin-total-functions",
            # "eslint-plugin-no-autofix",
            # "eslint-plugin-testing-library",
            # "eslint-plugin-jest-formatting",
            # "eslint-plugin-jest",
            # "eslint-plugin-etc",
            #
            # pre-commit required *explicitly* setting all dependencies, which is... annoying
            # (this is to prevent inconsistent dependency ranges and promote repeatability)
            # Dependencies of ESLint-Config-Beslogic
            "@eslint-community/eslint-plugin-eslint-comments@4.1",
            "@typescript-eslint/eslint-plugin@7.4",
            "confusing-browser-globals@1.0",
            "eslint@8.56.0",
            "eslint-import-resolver-typescript@3.2.6",
            "eslint-plugin-autofix@2.0",
            "eslint-plugin-extra-rules@0.0.0-development",
            "eslint-plugin-import@2.27.3",
            "eslint-plugin-no-relative-import-paths@1.5.3",
            "eslint-plugin-prefer-arrow@1.2",
            "eslint-plugin-regexp@2.0",
            "eslint-plugin-simple-import-sort@12.0",
            "eslint-plugin-sonarjs@1.0",
            "eslint-plugin-unicorn@49.0",
            "eslint-plugin-unused-imports@3.2",
            # Transitive dependencies of ESLint-Config-Beslogic
            "semver@6.3.1", # dependency of eslint-plugin-import
            "@typescript-eslint/parser@7.4", # dependency of @typescript-eslint/eslint-plugin
          ]

ci:
  autoupdate_schedule: quarterly

[asottile]

yes I've been slowly getting around to debugging this. it's specific to your patch for some reason and I haven't gotten to the bottom of it.

fwiw it isn't affecting anyone else so it's been lower priority

[asottile]

if possible please limit the commits made to that branch since it makes it more difficult to debug this problem when you're making a moving target :)

[Samuel-Therrien-Beslogic]

it's specific to your patch for some reason and I haven't gotten to the bottom of it.

fwiw it isn't affecting anyone else so it's been lower priority

Awesome! Good to know.

if possible please limit the commits made to that branch since it makes it more difficult to debug this problem when you're making a moving target :)

Certainly. Knowing you're on the case and there's nothing else to do but wait, I'll refrain from pushing anything to that branch. (it's not like it breaks my existing CI workflow anyway)

[asottile]

didn't get too far on this today -- locally it consumes a ton of ram (multiplied by n cpus) and then errors on some config file. that should still time out on pcci and be handled already but something is happening differently there before the run even starts from the logs. will have to dive deeper on an equivalent vm

[asottile]

I think I fixed this, or at least caused the runs to no longer be lost to the ether -- I believe the run of eslint was consuming all the memory and swapping forever. I've put better memory limits in place

can you rebase your branch? (it seems to be conflicting now preventing me from rerunning your change)

[asottile]

yep looks like that was the problem! now hitting OOM -- something in your linting pipeline is consuming a lot of memory: https://results.pre-commit.ci/run/github/771018559/1722215256.4fiKHgsGSZiOTrcMFSTEZg

[Samuel-Therrien-Beslogic]

Thanks! Now I can investigate what's making eslint consume so much memory during the run (at least that sounds like something I can maybe investigate locally w/o having to re-run pre-commit.ci everytime)