I've got following error while trying to send a message to a specific telegram channel:
TimedOut: Timed out
The read operation timed out
the method which I used from python-telegram-bot was send_message.
Although my bot got this error but it still sent the message to the channel and because I did not catch that exception all data from the message was lost but I really need to remove my messages from that channel after a specific period of time.
Is this OK that the bot sent the message even though it got Timed Out? How can I prevent this from happen again or remove this kind of messages from the channel after being sent?
Time out errors mean that TG didn't send a response to your send_message request quick enough. It does not necessarily mean that the request wasn't processed - that's why the message may still be sent. However, without response from TG, you don't have the message id of the resulting message and it will be hard to impossible to delete it.
You can try to increase the time that PTB waits for a response from TG. THis can be done in different ways:
with the timeout parameter of send_message
with Defaults.timeout, if you're using PTBs Defaults setup
by specifying it via the request_kwargs that you pass to Updater
You may want to have a look at this wiki page on networking.
Disclaimer: I'm currently the maintainer of python-telegram-bot
After a couple of hours reading here and there, and passing timeout=30 to context.bot.send_audio and getting an error that says unknown parameter even though send_audio's docs clearly states it takes a timeout param, I found that you can fix this by passing the timeouts to the Application upon building it:
application = ApplicationBuilder()
.token(bot_data["token"])
.read_timeout(30)
.write_timeout(30)
.build()
This fixed my bot. Hope this helps you as well.
Related
We are sending lots and lots of FCM Messages to our millions of users. As the message is triggered by an external event (Kick off in a football match) we sent many messages at the same time.
Sometimes the sending of an FCM message fails and we get an error message like this:
<H1>302 Moved</H1> The document has moved
<A HREF="https://fcm.googleapis.com/batch?
google_abuse=GOOGLE_ABUSE_EXEMPTION%3DID%....3B+expires%3DTue,+22-Nov-
2022+19:04:17+GMT">here</A>. </BODY></HTML>
(I removed some text for privacy reasons.)
For sending the messages we use
implementation 'com.google.firebase:firebase-admin:9.1.0'
We got thousands of error messages like this in one minute. In the next minute everthing worked fine again.
I have search the internet for information about it. But i couldn't find any abuse rules for FCM. Does anybody has information about this kind of error?
firebaser here
At first glance, your project may be getting throttled, but it may also be another problem in the API calls or the FCM backend. It’ll be challenging to pinpoint or even narrow down what is the specific cause of the error on a public forum without going into project-specific details. I would recommend reaching out to Firebase support as they can offer personalized help. Please provide the latest request and response (with timestamp) you have so they can check what happened to the message delivery.
I've encountered a problem when using small rye reactive messaging with Quarkus, for a rabbit MQ incoming handler.
The message being published to rabbit has a json content type, and the method signature of the handling code is written accordingly:
#Incoming("event-name")
#Acknowledgment(Acknowledgment.Strategy.POST_PROCESSING)
public void processEvent(final JsonObject payload)
However, in the event that the message body contains bad json, that cannot be parsed successfully, this method is never invoked and a io.vertx.core.json.DecodeException is thrown, when handling the failure this calls into the io.smallrye.reactive.messaging.providers.extension.HealthCenter.reportApplicationFailure() which then means the healthcheck endpoint will product a DOWN response. The app in question runs in k8s, so the pod gets restarted, but the new instance will pick up on the same message and produce the same. The only way to deal with the issue seems to be manually remove the bad message from the queue.
Looking in the docs https://quarkus.io/guides/rabbitmq-reference#health-reporting it suggests that a failed message should be nacked and the failure-strategy should handle it, but it seems because the message isn't being parsed properly, it isn't getting as a far as the processing, the the failure strategy isn't being called.
I'm actually not certain if this is the intended behaviour in this circumstance, if I can do something about it or if it genuinely is a bug - using Quarkus 2.12.0.
My expectation is that it should be possible to handle this circumstance in some way without causing the health check to fail and dequeueing the message so that the bad message isn't picked up again and again.
I play with nsqd a little bit and met the prob mentioned in the title. But when I send message via single nsqd, there is no such prob. Does this mean message should always be sent via same nsqd?
Here is my project. https://github.com/hoozecn/nsqd-cluster
It's resolved by set a higher MaxInFlight value.
ref: https://github.com/nsqio/nsq/issues/1213
We are having an issue with recovery for messages originating from Sagas.
When a Saga sends a message for processing, the message handler can sometimes fail with an exception. We currently use a try/catch and when an exception is thrown, we "Reply" with a failed message to the Saga. The issue with this approach is that Recoverability retries don't happen since we are handling the error in the message handler.
My thought was to add custom logic to the pipeline and if the Command message implements some special Interface, the custom logic would send a failed message response to the Saga if an exception occurs (after the retries fails), but I'm not sure where to plug into the pipeline that would allow me to send messages after retries fails.
Is this a valid approach? If not, how can I solve for Saga to Handler failure messages after retries?
You can use immediate dispatch to not wait for a handler to complete.
However, I would like to suggest an alternate approach. Why not create a Timeout in the saga? If the reply from the processing-handler isn't received within a certain TimeSpan, you take an alternate path. The processing-handler gets 5 minutes and if it doesn't respond within 5 minutes, we do something else. If it still responds after 6 minutes, we know we've already taken the alternate path (use a boolean flag or so and store that inside the saga data) and put aside the reply that arrived too late.
If you want to start a discussion based on this, check our community platform.
I'm using this FIX automation tool called VeriFIX to validate FIX messages. The problem I'm facing is, in my script I'm expecting an acknowledgement message from server in different session but there's a synchronization issue here.
The comes before my script arrives in that session and hence my scripts then keeps on waiting indefinitely for the message which has already being sent by the server.
Can anyone help me out on how to overcome this synchronization issue of VeriFIX, there are very limited options available with the tool and I couldn't find any thing useful.
What Sumbad is saying is the expected message has been received before the script has moved onto the step that expects the message.
To overcome this with veriFix Sumbad you should de-select the box that clears the queue after the last sucessfully received message.