invalid memory address or nil pointer dereference during `jf npm publish`

[narndt-inform]

Describe the bug

Hi folks,

we are currently experiencing an issue with the latest version of the JFrog CLI, 2.74.1 (also tested on 2.70.0 and 2.73.2).

Current behavior

We are trying to push an NPM package to our Artifactory instance, using the following command:

jf npm publish --registry=$TARGET_REPO --build-name=${SIMPLE_PROJECT_NAME} --build-number=${TARGET_VERSION} --project xxx

This results in the following crash:

npm notice package size: 4.8 MB
npm notice unpacked size: 13.9 MB
npm notice shasum: 5a129015116f135c9d7249a55f7c2e7fa8e757d9
npm notice integrity: sha512-23YxKZP9kZa15[...]qJjRjjQ8FXf0A==
npm notice total files: 1584
npm notice
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48 pc=0xb0b361]
goroutine 1 [running]:
github.com/jfrog/jfrog-client-go/utils/io/content.(*ContentReader).NextRecord(0x0, {0x1843340, 0xc000888080})
	/root/go/pkg/mod/github.com/jfrog/jfrog-client-go@v1.51.1/utils/io/content/contentreader.go:66 +0x61
github.com/jfrog/jfrog-client-go/artifactory/services/utils.ConvertArtifactsDetailsToBuildInfoArtifacts(0x0)
	/root/go/pkg/mod/github.com/jfrog/jfrog-client-go@v1.51.1/artifactory/services/utils/resultutils.go:87 +0xb1
github.com/jfrog/jfrog-cli-artifactory/artifactory/commands/npm.(*NpmPublishCommand).Run(0xc000437d40)
	/root/go/pkg/mod/github.com/jfrog/jfrog-cli-artifactory@v0.2.1/artifactory/commands/npm/publish.go:211 +0x3ca
github.com/jfrog/jfrog-cli-core/v2/common/commands.Exec({0x1e6e758, 0xc000437d40})
	/root/go/pkg/mod/github.com/jfrog/jfrog-cli-core/v2@v2.58.2/common/commands/command.go:36 +0x96
github.com/jfrog/jfrog-cli/buildtools.NpmPublishCmd(0xc0001b8f20)
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/buildtools/cli.go:941 +0x22f
github.com/jfrog/jfrog-cli/buildtools.npmGenericCmd(0xc0001b8f20, {0x7ffdde76a986, 0x7}, 0x0)
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/buildtools/cli.go:902 +0x135
github.com/jfrog/jfrog-cli/buildtools.GetCommands.func14.1(0x60?)
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/buildtools/cli.go:359 +0x1d
github.com/jfrog/jfrog-cli-security/cli.WrapCmdWithCurationPostFailureRun(0xc0001b8f20, 0xc0005b89c8?, {0x1b12a92, 0x3}, {0x7ffdde76a986, 0x7})
	/root/go/pkg/mod/github.com/jfrog/jfrog-cli-security@v1.16.1/cli/scancommands.go:488 +0x33
github.com/jfrog/jfrog-cli/buildtools.GetCommands.func14(0xc0001b8f20)
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/buildtools/cli.go:357 +0x169
github.com/urfave/cli.HandleAction({0x1791300?, 0x1c68818?}, 0x3?)
	/root/go/pkg/mod/github.com/urfave/cli@v1.22.16/app.go:524 +0x50
github.com/urfave/cli.Command.Run({{0x1b12a92, 0x3}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x1b3fb53, 0x10}, {0x1c14788, ...}, ...}, ...)
	/root/go/pkg/mod/github.com/urfave/cli@v1.22.16/command.go:175 +0x67c
github.com/urfave/cli.(*App).Run(0xc000105c00, {0xc000156000, 0x8, 0x8})
	/root/go/pkg/mod/github.com/urfave/cli@v1.22.16/app.go:277 +0xb3b
main.execMain()
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/main.go:133 +0x493
main.main()
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/main.go:70 +0x1c

I tried to look a bit into this, but couldn't find an obvious cause, so I'm opening an issue for this. To me, this looks related to jfrog/jfrog-cli#2499 (at least the stacktraces look similar, although the publish command itself was migrated to jfrog-cli-artifactory in the meantime). The debug log (export JFROG_CLI_LOG_LEVEL=DEBUG) does not reveal anything particularly interesting (produced with 2.73.2):

npm notice package size: 4.8 MB
npm notice unpacked size: 13.9 MB
npm notice shasum: 5a129015116f135c9d7249a55f7c2e7fa8e757d9
npm notice integrity: sha512-23YxKZP9kZa15[...]qJjRjjQ8FXf0A==
npm notice total files: 1584
npm notice
14:15:55 [Debug] Using npm executable: /usr/local/bin/npm
14:15:55 [Debug] Running 'npm --version' command.
14:15:56 [Debug] npm '--version' standard output is:
10.8.2
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x48 pc=0xb16221]

goroutine 1 [running]:
github.com/jfrog/jfrog-client-go/utils/io/content.(*ContentReader).NextRecord(0x0, {0x13540c0, 0xc000414e40})
	/root/go/pkg/mod/github.com/jfrog/jfrog-client-go@v1.49.1/utils/io/content/contentreader.go:66 +0x61
github.com/jfrog/jfrog-client-go/artifactory/services/utils.ConvertArtifactsDetailsToBuildInfoArtifacts(0x0)
	/root/go/pkg/mod/github.com/jfrog/jfrog-client-go@v1.49.1/artifactory/services/utils/resultutils.go:87 +0xb1
github.com/jfrog/jfrog-cli-core/v2/artifactory/commands/npm.(*NpmPublishCommand).Run(0xc000414cc0)
	/root/go/pkg/mod/github.com/jfrog/jfrog-cli-core/v2@v2.57.7/artifactory/commands/npm/publish.go:211 +0x3ca
github.com/jfrog/jfrog-cli-core/v2/common/commands.Exec({0x1847d50, 0xc000414cc0})
	/root/go/pkg/mod/github.com/jfrog/jfrog-cli-core/v2@v2.57.7/common/commands/command.go:36 +0x96
github.com/jfrog/jfrog-cli/buildtools.NpmPublishCmd(0xc000366580)
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/buildtools/cli.go:925 +0x22f
github.com/jfrog/jfrog-cli/buildtools.npmGenericCmd(0xc000366580, {0x7fffa59b4964, 0x7}, 0x0)
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/buildtools/cli.go:886 +0x135
github.com/jfrog/jfrog-cli/buildtools.GetCommands.func14.1(0x60?)
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/buildtools/cli.go:343 +0x1d
github.com/jfrog/jfrog-cli-security/cli.WrapCmdWithCurationPostFailureRun(0xc000366580, 0xc0003a1938?, {0x15a40b4, 0x3}, {0x7fffa59b4964, 0x7})
	/root/go/pkg/mod/github.com/jfrog/jfrog-cli-security@v1.14.1/cli/scancommands.go:554 +0x33
github.com/jfrog/jfrog-cli/buildtools.GetCommands.func14(0xc000366580)
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/buildtools/cli.go:341 +0x169
github.com/urfave/cli.HandleAction({0x12beb80?, 0x169b730?}, 0x3?)
	/root/go/pkg/mod/github.com/urfave/cli@v1.22.16/app.go:524 +0x50
github.com/urfave/cli.Command.Run({{0x15a40b4, 0x3}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x15cdd1c, 0x10}, {0x1670936, ...}, ...}, ...)
	/root/go/pkg/mod/github.com/urfave/cli@v1.22.16/command.go:175 +0x67c
github.com/urfave/cli.(*App).Run(0xc00036a1c0, {0xc000034080, 0x8, 0x8})
	/root/go/pkg/mod/github.com/urfave/cli@v1.22.16/app.go:277 +0xb3b
main.execMain()
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/main.go:134 +0x493
main.main()
	/var/xxx/workspace/eco-system/release/jfrog-cli-release/temp/jfrog-cli/main.go:71 +0x1c

Reproduction steps

$ node -v && npm -v
v20.18.2
10.8.2

Reproducing this might be tricky.. The change that caused the issue was upgrading the husky package from 8.0.3 to 9.1.7. Husky is an utility package to automatically install Git hooks on user machines, which can then be used to run unit tests / linters locally before pushing to a remote repository. We have HUSKY=0 set in our CI though, so normally this shouldn't have any impact on the build:

$ jf npm ci --build-name=${SIMPLE_PROJECT_NAME} --build-number=${TARGET_VERSION} --project xxx
> package-name@version prepare
> husky
HUSKY=0 skip install

We couldn't put together a minimal reproducible repository for you, but maybe this description already helps you with narrowing down the issue. Let me know if you need any further information!

Expected behavior

The publish command shouldn't crash, or if husky messes something up in the environment, at least tell me about it.

Thanks a lot in advance! 😄

JFrog CLI version

2.74.1

Operating system type and version

node:20.18.2-alpine (Docker Image)

JFrog Artifactory version

No response

JFrog Xray version

No response

[narndt-inform]

For those facing similar issues, we've found an acceptable workaround by only executing the prepare script if we're running in a non-CI environment. Looks like this in the package.json file:

"scripts": {
    "prepare": "is-ci || husky"
}

Regardless, it would be nice if the root cause of this error is fixed in the CLI though.

[venkatanrv]

Hi @narndt-inform

Thank you for raising this issue.

We've opened an internal Jira ticket to efficiently track this issue and allow our product team to review this issue. Consequently, we are now closing this GitHub issue. To receive updates on the Jira ticket, please open a support ticket and reference this GitHub issue.