Cannot send anything #412
Comments
|
An update regarding the latest version (0.68) that was released after I opened the issue: Now I am getting a different error: |
|
In addition to that when trying to send a message using the signal-cli directly from within the container, by running as the When running afterwards, I still get the error: |
|
@anotherbridge are you running in |
|
@mattwr18 Thanks for the hint. I indeed ran in And within the container after stopping the running signal-cli process and sending again: Running the challenge thereafter again, I'm getting basically the same error: |
|
@anotherbridge I don't have any experience with However, it's not clear what the error is. Is this the verbose output? |
|
Sorry, completely forgot about that issue. I'll have a look whether a different GraalVM version creates a valid native image. |
|
@mattwr18 Yes, this is the verbose output. Unfortunately it doesn't provide much information on why it gets the response.. I got that when executing where the |
* 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 the signal-cli native image build. So in order to make that work (again), we need to use our own libsignal_jni.so for the x86_64 build. see #412
|
The issue with the native mode should be fixed with the next release. If you want to give it a try, use the following docker image: |
|
@bbernhard I tested this out with One issue that I wanted to discuss is related to @anotherbridge first error posted in this issue. However, in I also received a second error with: It seems to be throwing an error due to the |
* 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 timestamp to an integer, it means that signal-cli returned some non-numeric characters as well (which is a strong indication that there was an error). So, instead of returning the parsing error, return the actual signal-cli error message. see #412
|
I've improved the error handling a bit. Can you maybe test the docker image |
|
@bbernhard I've done some quick initial testing and what I have encountered is that the changes introduced in ☝️ do in fact get rid of the As far I know though, not having a profile name set did not result in a 400 Bad Request, but when I set the profile name the error is no longer being reported. For the case where the number is still hitting the rate limit issue, for some reason the error message displayed in even though I can see the entire message from the output of |
* log the stdout & stderr buffers in case debug logging is enabled. see #412
yeah, it is a bit unfortunate, that a warning output in signal-cli is now reported as an error in the REST API. But not sure if there is much we can do about that. I mean, we could try to parse those warning messages, but I think this will be quite error prone :/ Unfortunately I can't reproduce the error here, as I do not run in any rate limiting issues. But I've added some debug logging to the In the docker log file you should see the following lines: Does the log file contain more information then you get back via REST? If you want to disable the debug logging again, simply restart the docker container. |
|
I get the same error as reported first by @anotherbridge with the latest docker. |
|
@bbernhard sorry it took so long to test this out. I was working on some other things and just got a chance to get back to it. Here is the output from the additional logging: This is the same info I get back via REST, but it is different from the info I get if I try to send the same message to the same number via |
|
@bbernhard I tested this with the latest https://github.com/bbernhard/signal-cli-rest-api/releases/tag/0.70 and now we get the error message containing the information needed to resolve the rate limit challenge. Thank you 💚 |
|
I just confirmed what @mattwr18 already stated! Regarding that also question came up whether it is possible to solve the challenge via the API or is it mandatory to solve it using the signal-cli from within the container? |
|
Currently that is only possible with signal-cli directly. But please create a new issue for that. |
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:
And the response is:
In the container logs I am seeing:
Are you using the latest released version?
Have you read the troubleshooting page?
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..
The text was updated successfully, but these errors were encountered: