Possible performance issues with lefthook v1.6.18

[korrat]

After updating lefthook (installed from nixpkgs) from v1.6.10 to v1.6.18, I'm seeing a 100x slow-down (0.1s to 10s) of my pre-commit hook. The pre-commit hook only has a single command, treefmt --fail-on-change {staged_files}.

So far, I've run the treefmt command by hand, which is fast (~microseconds).

Furthermore, lefthook leaves some output on the next prompt.

I'd love any help or suggestions to get to the bottom of this.

[mrexox]

This is interesting. Could you share you lefthook.yml config, so I could try reproduce?

[mrexox]

Unfortunately I couldn't reproduce this locally. I assume that there might be IO-related delays. Could you run the hook with LEFTHOOK_VERBOSE=true and try finding the place in logs where the delay happens?

It's also important: does the issue persist when you run the hook manually via lefthook run pre-commit or it only occurs when running implicitly via git commit?

[korrat]

The slowdown also occurs when running through lefthook run pre-commit.

 LEFTHOOK_VERBOSE=true lefthook run pre-commit -v 
│ [lefthook] cmd: [git rev-parse --show-toplevel]
│ [lefthook] err: <nil>
│ [lefthook] out: /home/korrat/workspace/gitlab.com/korrat/katas
                                                              
│ [lefthook] cmd: [git rev-parse --git-path hooks]
│ [lefthook] err: <nil>
│ [lefthook] out: .git/hooks
                          
│ [lefthook] cmd: [git rev-parse --git-path info]
│ [lefthook] err: <nil>
│ [lefthook] out: .git/info
                         
│ [lefthook] cmd: [git rev-parse --git-dir]
│ [lefthook] err: <nil>
│ [lefthook] out: .git
                    
│ [lefthook] cmd: [git hash-object -t tree /dev/null]
│ [lefthook] err: <nil>
│ [lefthook] out: 4b825dc642cb6eb9a060e54bf8d69288fbee4904
                                                        
╭───────────────────────────────────────╮
│ 🥊 lefthook v1.6.18  hook: pre-commit │
╰───────────────────────────────────────╯
│ [lefthook] cmd: [git status --short --porcelain]
│ [lefthook] dir: /home/korrat/workspace/gitlab.com/korrat/katas
│ [lefthook] err: <nil>
│ [lefthook] out: A  gilded-rose/test
                                   
│ [lefthook] cmd: [git diff --name-only --cached --diff-filter=ACMR]
│ [lefthook] dir: /home/korrat/workspace/gitlab.com/korrat/katas
│ [lefthook] err: <nil>
│ [lefthook] out: gilded-rose/test
                                
│ [lefthook] files before filters:
[gilded-rose/test]              
│ [lefthook] files after filters:
[gilded-rose/test]             
│ [lefthook] files after escaping:
[gilded-rose/test]              
│ [lefthook] executing: /nix/store/ivwycrcmgxlka73wi4a43l8dyfnld57g-treefmt-2.0.2/bin/treefmt --fail-on-change gilded-rose/test
# Slowdown occurs between these two lines.
┃  treefmt ❯ 

traversed 1 files
emitted 0 files for processing
matched 0 files to formatters
formatted 0 files in 210µs

│ [lefthook] cmd: [git stash list]
│ [lefthook] dir: /home/korrat/workspace/gitlab.com/korrat/katas
│ [lefthook] err: <nil>
│ [lefthook] out: 
                                      
  ────────────────────────────────────
summary: (done in 10.03 seconds)      
✔️  treefmt

[korrat]

I've spent some more time looking into this: I can reproduce the slowdown when running under strace. However, the accompanying trace shows that treefmt is started within one second of running lefthook, but waits twice on some futex until timing out after 5 seconds.

It seems the issue is not with lefthook itself, but somewhere in the interaction between treefmt and lefthook, probably helped by some edge case configuration on my part. Apologies for the misattribution.

[korrat]

A workaround & another hint: Setting interactive = true fixes the hang.

[mrexox]

Without interactive option the STDIN is just a null reader, so probably this was the problem, but with interactive the caller's TTY is being passed as STDIN. So, it make sense if treefmt expects TTY. Thank you for this investigation!

[korrat]

Similarly, setting CI=1 (either globally or for the command in lefthook.yml) also avoids the problem.