Error: unexpected end of JSON input

[terhechte]

I suddenly can't deploy anymore with doctl.

I'm just doing
./doctl serverless deploy --remote-build --verbose-build .

and am getting the following error:
Error: unexpected end of JSON input.

I tried:

• Update to the newest version via brew (I'm on macOS)
• Downloading the macOS binary and running ./doctl
• Switched to my Ubuntu machine and downloaded the latest doctl and tried the same. Same error.

I'd really like to deploy the fixes to my server less function but I can't.

[andrewsomething]

Hi @terhechte,

I have not been able to reproduce this issue. Can you provide any more information about your project that might help give us some insight? Is that the only output you received or was a build ID returned? What language runtime are you using?

As this doesn't seem to be a general doctl issue at first glance, I'd encourage you to open a support ticket. The support team has more context on your account and is able to discuss more details specific than in a public issue.

https://cloudsupport.digitalocean.com/

[crescentrose]

Hey @andrewsomething, I have the same issue. There also seems to be another thread (#1345) where people have a similar issue, though I cannot resolve it by building from source. I believe I've found the culprit, though, at least in my case: it's Nix 😅

I ran into this even with a fresh install from source using a sample:

$ doctl serverless deploy sample-functions-golang-helloworld --remote-build
Error: unexpected end of JSON input

Digging through your code (sorry) I noticed that a part of setting up the serverless environment includes downloading Node v18. Unfortunately Nix cannot run non-Nix executables, which is helpfully explained when I attempt to run this myself:

.config/doctl/sandbox is 📦 v5.0.19 via  
➜ file node
node: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=7aebc7ddb910e7aea69b7e4551441526a3cd6f22, with debug_info, not stripped, too many notes (256)

.config/doctl/sandbox is 📦 v5.0.19 via  
➜ ./node
Could not start dynamically linked executable: /home/ivan/.config/doctl/sandbox/./node
NixOS cannot run dynamically linked executables intended for generic
linux environments out of the box. For more information, see:
https://nix.dev/permalink/stub-ld

To verify this, I can do a very dirty hack that's sure to give any Nix nerd reading this an aneurysm:

$ nix-shell -p nodejs_18
(... it downloads ... )

[nix-shell:~]$ rm ~/.config/doctl/sandbox/node

[nix-shell:~]$ ln -s "$(which node)" ~/.config/doctl/sandbox/node

[nix-shell:~]$ doctl serverless deploy sample-functions-python-helloworld --remote-build
Deploying '/home/ivan/Code/sample-functions-python-helloworld'
  to namespace 'fn-68c1b4e9-e5d4-4517-8b78-86c24ac6b7e8'
  on host 'https://faas-ams3-2a2df116.doserverless.co'
Deployment status recorded in 'sample-functions-python-helloworld/.deployed'

Deployed functions ('doctl sls fn get <funcName> --url' for URL):
  - sample/hello

# yay!

I believe running doctl through Docker would work as a somewhat cleaner workaround. Another option I can think of is to wrap the doctl package in Nix with an overlay that also downloads Node v18 and symlinks it to where doctl expects it - the canReuseNode() function would pick up on it.

However, my $0.02 here is that I don't really expect doctl to download and set up Node or any other piece of software. At the very least it would be useful to have a flag to use a system-provided version of Node. But, I would strongly prefer that my software is open about the dependencies it uses so that it can be packaged correctly, and that it leaves package management to the package managers.

Please let me know if this helps or if you need more info (or testing) from my side. I would be happy to contribute a PR as well if you let me know what is your preference for the solution.