In Firebase console, the last Event message in Functions/Log section is "Function execution took 60006 ms, finished with status: 'timeout'". Is "timeout" the status the function is supposed to finish with? Or did I miss something in the code that would say "that's the end"?
You should send a response like res.send(200) at the end for it to terminate properly
Related
I have a very simple application for sending bulk messages.
It sends a single message to 20 groups.
The delay that I declare between send messages is "8".
It means about 7~8 send message request per minute.
The documentation says "telegram api has a limit of 20 request per minute".
It means I am using less than half of the limit.
But still, I am getting lots of flood wait errors.
And those wait errors has like 84.000second wait limit.
I am facing 2 errors while getting floodwait error.
1-
Security error while unpacking a recevied message: Server replied with a wrong session ID
2-
Floodwaiterror invoked while sending a message; forcing 70792 second wait interval for ....
I really don't know why this is happening.
The number I am trying to send message is brand new. Clear. Unbanned. Unspammed.
As I said wait interval between 2 messages is 8 seconds, means less than the limits for a minute.
Sessions are correct because it sends couple message but after couple it gets instantly tons of floodwaiterrors from 0 to 70k.
Could you help me to understand what is causing that please?
I have the same problem and solution is to pass the entity object instead of string name of receiver party.
was:
results = await client.send_message("mybot", message="hello")
now:
with TelegramClientSync(StringSession(session_id), api_id, api_hash) as client:
bot_entity = client.get_input_entity(peer="mybot")
results = await client.send_message(entity=bot_entity, message=message)
Having a Firebase Callable Function, for "handled" errors (not exceptions) occurring during execution, I throw new HttpsError(...)'s to notify the client that an error occurred and handle them appropriately.
For monitoring the healthiness of the Cloud Functions, I'm using Google Cloud Monitoring. Therefore I wanted to set up an alert that alerts based on the following query if something really goes wrong (unhandled exception, whatever other errors could occur during function execution):
What I want to have is exception alerting - so if a Cloud Function fails because during an execution an uncaught exception gets thrown, I want to be alerted.
But I do not want this alert to fire if I intentionally "return" (throw) this special HttpsError which is thrown in cases of misuse or "handled" errors (like authentication failure):
throw new HttpsError('permission-denied', 'Access denied')
My question is now whether Cloud Functions that throw HttpsError(...) count as status = "error" or if they count as status = ok in Cloud Monitoring.
My feeling is they count as error (as the alert fires sometimes) but if I then look in the Firebase Console's Function log, they do not show up as error there. So they do not have the red exclamation mark:
Instead there, the log just says something like ...finished with status code: 204
That's what makes me wonder if an error in Cloud Monitoring is just every function that ended with "Http Status code != 200"
If throwing an HttpsError does count as error, how could I query only functions that crashed/did not execute as intended for my alert?
I'm throwing an error from my callable Firebase function:
throw new functions.https.HttpsError(
'invalid-argument',
`Invalid token ${token} for file ${fileName}.`
);
I the logs I see only the following:
12:29:22.500 PM SQR-cancelAllotment Function execution took 1779 ms, finished with status code: 400
12:29:20.722 PM SQR-cancelAllotment Function execution started
So, code 400 is indicated without any error message. Why?
I wouldn’t like to duplicate the error message in a separate console.error.
Throwing an HttpsError is a signal to the client that the function didn't work as expected. It's not an indication that the function terminated with a crash (which would be logged). When you throw an HttpsError, if you want to see a message in the log, you should also make a call to console.error() (or whatever log level you want) in order for that to show up.
For throwing errors in Cloud Functions you could use the Stackdriver Error Reporting client libraries
Here you can find the documentation for setting up the error reporting ( you have some examples there,also)
We have a cloud function set up with pub/sub triggers.
The function is invoked topic(NAME).onPublish()
If the function is invoked when it is cold, it always runs twice.
Function execution took 284 ms, finished with status: 'ok' METHOD_NAME METHOD_ID
Received message from pub sub METHOD_NAME METHOD_ID
Function execution started METHOD_NAME METHOD_ID
Function execution took 24271 ms, finished with status: 'ok' METHOD_NAME METHOD_ID
Received message from pub sub METHOD_NAME METHOD_ID
Function execution started METHOD_NAME METHOD_ID
After that all future messages only run once, until the function goes cold again.
Is this because it takes a long time for the first invocation to complete and the timeout causes it to be run again? Any way to prevent this?
Startup time is almost for sure the issue. To verify this, try these:
comment out portion of the function until fast, to see if the problem goes away (time it in your local terminal, if you can, using timeit module)
increasing Acknowledgement Deadline seconds (upon subscription); defaults to 10 so could easily be the problem; try 20, 40 etc
ensure that the first time run, the function takes less time than the Timeout value of the function (defaults to 60 seconds - not likely to be the problem)
I'm puzzled at what we see when running this setup:
FuncA: Google Cloud Function trigger-http
FuncB: Google Cloud Function trigger-topic
FuncA is called by a HTTP client. Upon being called, FuncA does some light work setting up a JSON object describing a task to perform, and stores this JSON into Google Cloud Storage. When the file has been written FuncA published a topic with a pointer to the gs file. At this point FuncA responds to the client and exits. Duration typically 1-2 seconds.
FuncB is informed that a topic has been published and is invoked. The task JSON is picked up and work beings. After processing FuncB stores the result info Firebase Realtime Database. FuncB exits at this point. Duration typically 10-20 seconds.
As FuncA and FuncB are in no way associated, live their individual process lifecycles on different function names (and triggers) and only share communication through pub/sub topic message passing (one-direction from A to B) we would expect that FuncA can run again and again, publishing topics at any rate. FuncB should be triggered and fan-out to scale with what ever pace FuncA is called with.
This is however not what happens.
In the logs we see results following this pattern:
10:00:00.000 FuncA: Function execution started
10:00:02.000 FuncA: Function execution took 2000 ms, finished with status: 'ok'
10:00:02.500 FuncB: Function execution started
10:00:17.500 FuncB: Function execution took 15000 ms, finished with status: 'ok'
10:00:18.000 FuncA: Function execution started
10:00:20.000 FuncA: Function execution took 2000 ms, finished with status: 'ok'
10:00:20.500 FuncB: Function execution started
10:00:35.500 FuncB: Function execution took 15000 ms, finished with status: 'ok'
...
The client calling FuncA clearly gets to wait for both FuncA and FuncB to finish, before being let through with the next request. It is expected that FuncA would finish, and allow a new call in immediately at what ever pace the calling client can "throw at it".
Beefing the client up with more threads only repeats this pattern, such that "paired" calls to FuncA->FuncB always waits for each other.
Dicsuss, clarify, ... stackoverflow, do your magic! :-)
Thanks in advance.