Wondering if there are any costs when the response has statusCode = 429
CosmosException "x-ms-request-charge" header is 0, so seems that it is not charged, but wondering if there are not CosmosDB charges at all.
The same question can be extended to others such a 4xx such as 400 Bad Request
There is no Request Unit (RU) charge when you receive a 429, as a 429 is telling you that your query cannot be processed due to rate-limiting.
The one thing to do, once getting the 429, is wait the number of ms in that 429 message, before making the request again.
Cosmos DB doesn't have any other charges, aside from the per-hour cost of your various databases & collections.
Related
From time to time, I see this error in Application Insights in Failures => failed dependencies :
Been searching through the documentation, but cannot see this mentioned anywhere. Does this status mean that the operation was cancelled through the token, or is it similar to the cross-partition response that used to be an 400 error? (https://github.com/Azure/azure-cosmos-dotnet-v2/issues/606#issuecomment-427909582)
Also, will this action be retried or is there loss of data for this?
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)
A large number requests over our Azure API Management result in the ClientConnectionFailure exception.
By querying the logs I see two variants of the error:
exceptions
| where cloud_RoleName == "..."
| summarize num = count(itemCount) by problemId, outerMessage
| order by num
problemId: ClientConnectionFailure at transfer-response, outermessage: A task was canceled, count 403,249
problemId: ClientConnectionFailure at forward-request, outermessage: The operation was canceled, count 55,531
Based on this post, the problem could be time-outs or that clients abandon connections. With response times generally within 500ms I'm inclined to rule out the first.
The question is: what is the difference between transfer-response and forward-request, and does it provide any clues as to what is going on?
Transfer-response means that the client dropped the connection after it started receiving the response.
Forward-request means that the client dropped the connection while the APIM gateway was sending the request to the back end or waiting for a response from the back end.
I'm encountering a problem where, the Azure Cosmos DB is giving Status Code: 403 Storage quota for 'Document' exceeded message for documents which are less than, 2 MB in size. I know, there is a limit on the document size but, in this case I tried with 5 KB document and it gave the same message. I'm using documentdb for storing JSON data.
According to
https://learn.microsoft.com/en-us/rest/api/documentdb/http-status-codes-for-documentdb
403 is also returned during a POST to create a resource when the resource quota has been reached. An example of this is when trying to add documents to a collection that has reached its provisioned storage.
I have encountered this when I have tried to push more data into a partition when its size has already reached 10 GB.
I've been using Firebase for one of my games and while it's been an extremely useful service and tool I happened to come across an issue that I didn't address during development which has allowed users to cheat.
As you would expect with Firebase that introduces most of the logic on the client side, I have client-side authorization in place, which was a mistake from the start to begin with. The issue that I'm running into is the following. Please note that this is not my structure, just an example to work from.
{
"user":
{
currently_training: false,
current_units: 673,
unit_cap: 1000
}
}
The client would take this and tell the user, "Okay, you're only allowed to train (1000 - 673) = 327 units. However, by bypassing this on the client side to change the unit_cap to lets say 10,000 the user can now send a request to the database to create 9,327 units, which will result in his units exceeding his unit cap.
How would I go about validating a query, such as..
- User requests to train 412 units.
- Insert is not executed as the amount of requested units + current_units > unit_cap
- Error is sent back to client to be handled.
OR
- User requests to train 300 units.
- 300 + current_units <= unit_cap
- Insert executes successfully.
OR
- User requests to train 300 units.
- 300 + current_units <= unit_cap
- currently_training is true, so the Insert fails with error.
I'm fairly worried that creating a middleware server is going to be required, which is the reason I went with firebase to begin with. (So I wouldn't have to worry about the scalability of my own servers)