We are using twilio for sending messages but as Twilio(Text Messaging) integration was shutting down we deployed the integration using cloud run by following steps from https://github.com/GoogleCloudPlatform/dialogflow-integrations/tree/master/twilio#readme
After deployment messages were sending successfully but now suddenly we are getting errors in twilio like
Some messages are sending successfully and for some messages we are getting error.can anybody help me in this.thanks in advance
According to Twillio docs there might be some possible causes for Unreachable destination handset
1.The destination handset you are trying to reach is switched off or otherwise unavailable.
2.The device you are trying to reach does not have sufficient signal
3.The device cannot receive SMS (for example, the phone number belongs to a landline)
4.There is an issue with the mobile carrier
Possible Solutions
The first step to troubleshooting this issue is to attempt to replicate the problems.
Attempt to send another test message to this user via a REST API request, or through the API Explorer in the Twilio Console.
Related
I have a django application that routinely injects messages into an Azure service bus. I am receiving intermittent errors indicating that its messages are unauthorized. I would say that 95% of messages are successfully authorized, with about 5% unauthorized).
I have not changed anything in months related to access (shared access signatures, access keys etc) to the service bus, and I have validated that my python code is still using all the correct values (service bus namespace, topic, access key, etc).
Despite this, I am receiving intermittent errors related to having an invalid authorization token signature:
"AzureHttpError('SubCode=40103: Invalid authorization token signature',)`
How can I correct this, and how can I find out the cause?
From what I can see here in the documentation, the token is generated using a few things:
SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>
You said you've checked the access key, so maybe you should check is your time on your server/computer/device has a correct and stable clock.
For debugging you can just write a log before the service bus call to print the current timestamp of your server and work out whether it is correct.
We have been following the tutorial here: https://cloud.google.com/community/tutorials/cloud-iot-gateways-rpi
We set up the registry, gateway and devices, and we validated that the gateway (laptop) is connected. Google Cloud console showing gateways
We get the message below on the gateway:
Creating JWT using RS256 from private key file rsa_private.pem
connect status False
on_connect Connection Accepted.
on_subscribe: mid 1, qos (1,)
Unable to find key 1
Received message '' on topic '/devices/test-gateway/config' with Qos 1
Nobody subscribes to topic /devices/test-gateway/config
Received message '' on topic '/devices/test-gateway/config' with Qos 1
Nobody subscribes to topic /devices/test-gateway/config
However, in the Raspberry Pi, it says "Waiting for Response" and the device was waiting for response and does not get to the "received" step. Please see attached screenshots of the raspberry pi output as well as the google cloud Iot Core that shows that the gateway is connected.Raspberry Pi console output
As Gabe and Kolban mentioned, there's a lot of complexity in the examples from the community tutorials that can make it difficult to understand where things are breaking for you. I recommend starting from the samples available here for getting started.
In the example you're running, the gateway server must be running before the thermostat or led-light code is run.
Also, in the Raspberry Pi code, without a DHT-22 sensor connected to the Raspberry Pi, you will not reach the code where the readings are taken. If you're looking for a version that doesn't require hardware, the python-docs-samples version of ledlight and thermostat simulate the hardware. I have verified that the instructions work at a minimum for the led-light portion of the demo (I was able to turn on / off the LED light).
Finally, there might be an error in the tabulation for the source code on line 51 of thermostat.py that causes some issues in the UDP protocol. I'll update the article if I can verify that is causing hiccups for me but if you want to patch your copy before that's republished, set the code to look like:
# Receive response
if log:
print('waiting for response', file=sys.stderr)
response, _ = sock.recvfrom(4096)
if log:
print('received: "{}"'.format(response), file=sys.stderr)
Question on why pubsub requests seem to trigger such a high number of 503 errors? Is this something common? It seems other people see something similar but a majority of my requests end up that way
Similar to
Google Pubsub: UNAVAILABLE: The service was unable to fulfill your request
Catch error code from GCP pub/sub
This is expected behavior. Streaming pull, which is used by the client libraries, creates a bidirectional stream for receiving messages and sending back acknowledgements. These streams stay open for long periods of time and don't close with a successful response code when messages are received, they terminate with an error condition when the stream disconnects, perhaps due to a restart on the part of the server receiving the request or because of brief network blip. Therefore, even if you are receiving messages successfully, you'll still see error response codes for all of the streams themselves. The new streaming pull docs address this question directly.
We have 2 React Native app are using AWS Cognito for authentication. We use library react-native-aws-cognito-js in our code. The apps are working fine until these 2 days. Apps are experiencing intermittent "Internal Server Error".
How can I find more information about this error? Any tool can help us pinpoint the cause?
Update
From CloudTrail, each API call has an event "CreateNetworkInterface". Many of such API calls have error code "Client.NetworkInterfaceLimitExceeded". What is the cause and solution to this?
According to this AWS Doc (in Chinese), CloudWatch will not write to log when error is due to insufficient IP/ENI. That explains the increase in error number but no logs in CloudWatch.
Upate 2
We have found a scheduled Lambda job which may exhausted IP addresses. We stopped the batch job. But still can't have too many user login to server due to "Client.NetworkInterfaceLimitExceeded" error. I realized that there are many "CreateNetworkInterface" event and few "DeleteNetworkInterface" event. How can I "clean up / reset" all network interface in VPC?
Short answer: Cloud Trail.
Long answer with a suggestion
Assuming your application code is fine, most likely the cause of your 500 error is based on Cognito's initial limitations (e.g., number of calls per user): https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html.
AWS suggests to use Cloud Trail, for logging Api calls.
However I would suggest, to prove the limitations first, add some logs around the api call yourself, and in development you could call your app/api with a high number of calls; and most likely you will see the 500 error due to the limitations.
You could do the following in the terminal:
for i in `seq 1 1000`; do curl --cookie SecureCookie=TokenValueFromAWS http://localhost:desirablePort/SecuredPath; done
Iam trying to send a message to activemq using pythons stompclient.
https://bitbucket.org/hozn/stompclient/wiki/User%20Documentation
If there is a better library for this Im open to suggestions.
If i change to ip or port it will fail to connect so im assuming that the connection is working. There are no errors when I run this code its just that I see no messages on the queue. I think the destination path is possibly where it is failing the PhysicalName of the activemq queue is in this pattern 'abc.queue_name'.
I've tried the following destinations
/queue/abc/queue_name
/queue/abc.queue_name
abc.queue_name
Any suggestions are greatly appreciated.
Thanks
from stompclient import PublishClient
client = PublishClient('IP', 53680)
response = client.connect('defaultPassword', 'defaultUser')
reponse1 = client.send('/queue/abc/queue_name', 'bla')
time.sleep(5)
Have you checked the webconsole to see if your Queue was created by the send?
You should also try adding a request id onto the send and waiting for a response, this will ensure that the broker has enough time to get the sent data before you client code disconnects.
You might also want to check the Broker logs to see if any errors are logged or any security warnings in case the user doesn't have publish rights.
Added this property to the activemq.xml file and im now seeing messages on the queue via the web console.
<transportConnector name="stomp" uri="stomp://0.0.0.0:61613"/>