Cannot close polls (on ARM64): class java.lang.Integer cannot be cast to class java.lang.Long

[murderbeard]

The problem

Trying to close polls on my Raspberry Pi 5 (MODE=json-rpc) gives me a 400 Bad Request error. The returned error is as follows. As far as I can follow the timestamp is read as a 64-bit number in ClosePoll() in api.go and is passed on as such but I guess at some point where it reaches the signal-CLI it's turned into a 32-bit int or something.

< HTTP/1.1 400 Bad Request
< Content-Type: application/json; charset=utf-8
< Date: Mon, 04 May 2026 14:12:52 GMT
< Content-Length: 180
<
* Connection #0 to host localhost left intact
{"error":"class java.lang.Integer cannot be cast to class java.lang.Long (java.lang.Integer and java.lang.Long are in module java.base of loader 'bootstrap') (ClassCastException)"}

Are you using the latest released version?

• Yes

Have you read the troubleshooting page?

• Yes

What type of installation are you running?

signal-cli-rest-api Docker Container

In which mode are you using the docker container?

JSON-RPC Mode

What's the architecture of your host system?

arm64

Additional information

No response

[bbernhard]

That's weird. I tried it on my (x86-64) machine, but for me everything seems to be working fine. Even when emulating an arm64 system, I wasn't able to reproduce the issue. Does this problem only happen with the json-rpc mode? Could you please post the (obfuscated) REST call you are using.

[murderbeard]

I've run some more test and had the same result when running in normal mode. But I discovered it does successfully close polls when I send the request via CURL from my Windows machine.

For more context I'm using Homey for home automation and it has several cards you can use in its visual programming node editor, which can do web request. It seems that that system doesn't send the body you put in 'as is' but does some post processing. I guess it deems the timestamp to be a number and omits the quotes. And when the timestamp is sent as a number the above issue happens. I've sent out a message to the developers to see if indeed they are doing this kind of post processing.

So this isn't an issue after all, unless you want to timestamps to be allowed to be a number as well as a string.