signal-cli-rest-api: Cannot send anything
The problem
After registering a number on a fresh container with no prior configuration I am not able to send any messages.
Command that was run:
curl -X POST -H "Content-Type: application/json" 'http://localhost:8080/v2/send' -d '{"message": "Test via Signal API!", "number": "<sender>", "recipients": [ "<recipient>" ]}'
And the response is:
{
"error": "WARN SendHelper - Failed to send message due to IO exception: Unable to parse entity\nFailed to send message\n"
}
In the container logs I am seeing:
[GIN] <timestamp> | 400 | 6.6703771s | 10.0.2.100 | POST "/v2/send"
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?
Native Mode
What’s the architecture of your host system?
x86-64
Additional information
I encountered this issue in all modes, i.e. normal, native and json-rpc.
Further, I have a version where a number was registered under version 0.64 and strangely when mounting this configuration directory, I can do everything without any problems…
About this issue
- Original URL
- State: closed
- Created 9 months ago
- Comments: 17 (5 by maintainers)
Commits related to this issue
- fixed signal-cli-native build * due to different glibc versions, it is not possible to use the existing (prebuilt) libsignal_jni.so that get's shipped with the signal-cli binary distribution for ... — committed to bbernhard/signal-cli-rest-api by bbernhard 9 months ago
- improved error handling in send method * when a message is successfully sent, signal-cli returns a timestamp, which we convert to an integer. in case, we, for some reason can't convert the timest... — committed to bbernhard/signal-cli-rest-api by bbernhard 9 months ago
- add debug logging to cli client * log the stdout & stderr buffers in case debug logging is enabled. see #412 — committed to bbernhard/signal-cli-rest-api by bbernhard 9 months ago
Sorry, completely forgot about that issue. I’ll have a look whether a different GraalVM version creates a valid native image.
An update regarding the latest version (0.68) that was released after I opened the issue:
Now I am getting a different error: