Ghost/indirect dependency on a custom package
82 views
Skip to first unread message
Peter Bočan
Feb 20, 2024, 5:07:24 AMFeb 20
to golang-nuts
Hello Gophers!
I am facing a very odd issue. I have recently joined a company and wrote a small database migration binary which is co-located in the same github repo as the service which database migrations it.
For whatever reason the DB migration binary, when it runs on the cluster, it manages to connect to AWS SQS and consume messages from a queue, however I don't see any direct and indirect dependency on the package which implements the SQS connectivity.
The service (the repo in which the binary is located) does consume the SQS package. Just to be clear, we have a "utils" repo (yeaaaaahhhh, I know.) which contains all the fun bits among which is this SQS client library.
service (repo) -> utils (repo)
migrations (binary) -> utils (repo) but only uses the database package.
The migrations binary is compiled from the repo root directory: go build cmd/migrations/main.go
I am fairly dumbfounded and have a very hard time tracking the dependency (initialization) order. On the upside there are no relevant "init" functions.
Is there a way to debug this? Is there a way to step over the initialisation order?
Cheers,
Peter.
I am facing a very odd issue. I have recently joined a company and wrote a small database migration binary which is co-located in the same github repo as the service which database migrations it.
For whatever reason the DB migration binary, when it runs on the cluster, it manages to connect to AWS SQS and consume messages from a queue, however I don't see any direct and indirect dependency on the package which implements the SQS connectivity.
The service (the repo in which the binary is located) does consume the SQS package. Just to be clear, we have a "utils" repo (yeaaaaahhhh, I know.) which contains all the fun bits among which is this SQS client library.
service (repo) -> utils (repo)
migrations (binary) -> utils (repo) but only uses the database package.
The migrations binary is compiled from the repo root directory: go build cmd/migrations/main.go
I am fairly dumbfounded and have a very hard time tracking the dependency (initialization) order. On the upside there are no relevant "init" functions.
Is there a way to debug this? Is there a way to step over the initialisation order?
Cheers,
Peter.
Jan Mercl
Feb 20, 2024, 5:19:04 AMFeb 20
to Peter Bočan, golang-nuts
On Tue, Feb 20, 2024 at 11:07 AM Peter Bočan <peppy...@gmail.com> wrote:
> Is there a way to debug this? Is there a way to step over the initialisation order?
I try to get help from '$ go mod graph' in similar investigations.
> Is there a way to debug this? Is there a way to step over the initialisation order?
Peter Bočan
Feb 20, 2024, 5:29:19 AMFeb 20
to golang-nuts
That seems to work on the repo/go.mod level, if I am not mistaken. I would need something finer on the binary/compilation unit level.
Peter.
Peter.
Mike Schinkel
Feb 20, 2024, 1:14:43 PMFeb 20
to golang-nuts
Is there no `cmd/migrations/go.mod`?
Have you not tried debugging with Delve?
-Mike
Reply all
Reply to author
Forward
0 new messages