Does upgrading goland locally break pants? A user ...
# general
l
Does upgrading goland locally break pants? A user of our monorepo upgraded from
1.21.1
to
1.21.2
on their machine and the
go
build started to fail with:
Copy code
➜ pants check src/go::
...
__run_go.sh: line 14: /opt/homebrew/Cellar/go/1.21.1/libexec/bin/go: No such file or directory
__run_go.sh: line 14: exec: /opt/homebrew/Cellar/go/1.21.1/libexec/bin/go: cannot execute: No such file or directory

15:52:53.84 [ERROR] 1 Exception encountered:

Engine traceback:
  in `run` goal - ***

Exception: Failed to compile main:

__run_go.sh: line 14: /opt/homebrew/Cellar/go/1.21.1/libexec/bin/go: No such file or directory
__run_go.sh: line 14: exec: /opt/homebrew/Cellar/go/1.21.1/libexec/bin/go: cannot execute: No such file or directory
To fix the issue, they had to re-install pants. Thoughts?
h
Hmm, looks like a cache invalidation issue perhaps. That
1.21.1
path seems to be cached.
l
Yep, any way to forcefully invalidate?
h
You can try reproducing this but killing the pantsd process after the upgrade, and then again but killing the pantsd process and deleting
~/.cache/pants/lmdb_store/
That will shed some light
l
hmm, ok so I didn’t run into this issue myself after upgrading my local go version to
1.21.2
. Might be a random / rare edge case
Might suggest cleaning the cache directory you recommended next time this happens or running through the steps above to get more info
h
If you can reproduce consistently, getting that info would be great!
👍 1
l
will do
h
Oh, after you upgraded did you see log lines like these?
Copy code
07:59:03.76 [INFO] Initializing scheduler...
07:59:13.63 [INFO] Scheduler initialized.
That means
pantsd
started up
l
When I upgraded just now:
Copy code
==> Pouring go--1.21.2.monterey.bottle.tar.gz
🍺  /usr/local/Cellar/go/1.21.2: 12,535 files, 242.7MB
==> Running `brew cleanup go`...
I immediately tried running one of our apps:
Copy code
o11y (main) $ pants run ingestion:bin@environment=macos_x86_64
[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.
.
.
no scheduler logs, but after killing the process, the logs showed up
the user that ran into this issue didn’t see the scheduler log as well after the go upgrade. not sure if any of this is helpful, and seems hard to reproduce
we wanted to move past the error so we just reinstalled pants, wish we kept that state to provide more context
h
Well, as long as you found a solution! If you happen to hit it again, and can get some debug info, that would be great. A consistent way to reproduce the problem would of course be the gold standard.
l
agreed. we’ll be onboarding more and more devs to the repo so I’ll keep and I out for this error should it show up again. thanks for the quick response on this 👍
🙏 1