I have been integrating with the Uber Delivery API for a while now and things have been going well. However, a week ago, a delivery was posted to the API and the status of the delivery remained as "processing" for at least 20 minutes. Because the delivery was time sensitive for our company, we needed to cancel this delivery and schedule a new one. Is this supposed to happen? I would think that the "processing" status would eventually time out and then display a failure status.
Processing does time out if Uber deliveries cannot find a driver (no_couriers_available). This is where deliveries spend 30 minutes in a state looking for a courier.
There is a DELETE method on /v1/deliveries/:id for cancelling in progress ones (as you used).
Related
In testing code that uses the SendGrid Email Activity API, I have received "too many messages" errors. I have examined the "rate limit" response headers and it appears that I am being limited to 10 requests per 5 minute block in the day. That is, the first 5 minutes of every hour can have 10 requests, the next 5 minutes can have 10 requests, etc.
I asked SendGrid support about this. The first response was pretty generic, but seems to indicate that the threshold is correct and says I really should be using webhooks to get the status. I haven't found anything in the documentation saying this and I haven't seen anything the specifies what the rate limits are.
For those of you using the Email Activity API, are you limited to 10 requests per 5 minutes? If yes, what do you do with the API?
Here's an snippet of what I ended up using with requests, tenacity and ratelimit:
from ratelimit import limits, sleep_and_retry
import requests
import tenacity
#sleep_and_retry
#limits(calls=2, period=60)
#tenacity.retry(
retry=tenacity.retry_if_exception_type(requests.exceptions.HTTPError),
stop=tenacity.stop_after_attempt(10),
wait=tenacity.wait.wait_fixed(60),
)
def _call_api(headers, params):
response = requests.get(
"https://api.sendgrid.com/v3/messages",
json={},
headers={},
params={},
)
try:
response.raise_for_status()
except requests.exceptions.HTTPError:
logger.info(f"Request failed {response.headers}, retrying in 1 minute")
raise
return response
I received a response from SendGrid support that says:
Your findings are correct in that we do limit this endpoint to 10 requests per 5 minutes. This is a hard limit that we do not have the means of raising. The Email Activity Feed as well as the Email Activity API endpoint are meant for troubleshooting specific issues and attaining detailed message metadata.
I previously found the rate limit to be 10/5min but it appears that SendGrid have changed the rate limit to 2 requests every 60 seconds sometime in the past week. Can anyone confirm this?
I'm using the webhook to report non-delivery back to my application but I also need to use the activity API to resolve async bounce notifications. Async bounces are when a destination mail server accepts a message during the smtp session but subsequently sends a bounce notification email. When this occurs, SendGrid do not provide the detail of the bounced message in the webhook and the message is incorrectly reported as delivered in the SendGrid app. When asked, they respond that there's nothing they can do about it, even though I have explained to them how I use their activity api to resolve this.
I pay extra to use the activity API to fix a problem that they should address themselves, so I'm very frustrated that they apply such restrictive rate limits, then change them without notice.
Paypal documentation for PayPal Sync API (https://developer.paypal.com/docs/api/sync/v1/).
It gives some mysterious date, named "last_refreshed_datetime".
On the sandbox server it is usually in the past, once it was a few days in the past, now it is 2 hours in the past.
What does it mean? How often it refreshes?
I only know that if I create a transaction it will not be visible on PayPal Sync API until the refresh date will not be later than the transaction date. And I'm guessing it should be the transaction approval date that does not presented on this report. The transaction approval date is available on transaction object (https://developer.paypal.com/docs/api/subscriptions/v1/#definition-transaction), it is called "time".
time string
The date and time when the transaction was processed, in Internet date and time format.
Read only.
I have reached out to the product development team for the SYNC API and have gotten the following clarifications in regards to your questions:
If the "last_refreshed_datetime" (Time until which we have data available in our system) is smaller than the requested end date then, in the API response we show end date as "last_refreshed_datetime". As we only have data up until that point. In general there should be around 4-6hrs of delay.
From my own experience on sandbox, on different occasions it was 6.5, 2.5 hours and even 2 days behind.
In our design we have something of a paradox. We have a database of projects. Each project has a status. We have a REST api to change a project from “Ready” status to “Cleanup” status. Two things must happen.
update the status in the database
send out an email to the approvers
Currently RESTful api does 1, and if that is successful, do 2.
But sometimes the email fails to send. But since (1) is already committed, it is not possible to rollback.
I don't want to send the email prior to commit, because I want to make sure the commit is successful before sending the email.
I thought about undoing step 1, but that is very hard. The status change involves adding new records to the history table, so I need to delete them. And if another person make other changes concurrently, the undo might get messed up.
So what can I do? If (2) fails, should I return “200 OK” to the client?
Seems like the best option is to return “500 Server Error” with error message that says “The project status was changed. However, sending the email to the approvers failed. Please take appropriate action.”
Perhaps I should not try to do 1 + 2 in a single operation? But that just puts the burden on the client, which is worse!
Just some random thoughts:
You can have a notification sent status flag along with a datetime of submission. When an email is successful then it flips, if not then it stays. When changes are submitted then your code iterates through ALL unsent notifications and tries to send. No idea what backend db you are suing but I believe many have the functionality to send emails as well. You could have a scheduled Job (SQL Server Agent for MSSQL) that runs hourly and tries to send if the datetime of the submission is lapsed a certain amount or starts setting off alarms if it fails as well.
If ti is that insanely important then maybe you could integrate a third party service such as sendgrid to run as a backup sending mech. That of course would be more $$ though...
Traditionally I've always separated functions like this into a backend worker process that handles this kind of administrative tasking stuff across many different applications. Some notifications get sent out every morning. Some get sent out every 15 minutes. Some are weekly summaries. If I run into a crash and burn then I light up the event log and we are (lucky/unlucky) enough to have server monitoring tools that alert us on specified application events.
For eg: ride was in progress for 1 day ! Or ride was accepted, but neither the rider or driver, it any action on it. Does this generate webhook callback ?
I am using sandbox-api as of now. My ride just expires after some time(1 hour may be) and I get ClientError when trying to get the ride details. On rebooking, I get a new ride id. I do not know if webhook is firing callback or not, as I do not have a CA certificate as of now on my server listening to callback. Will this happen in production api also ?
Unfortunately our sandbox isn't perfect and doesn't mimic production behavior 100%. In the production environment a trip in the "processing" stage is cancelled after around 2 minutes if no suitable driver is found.
Regarding the duration of a real trip...I don't think we have any hard limit on that. If the driver and passenger mutually agree to keep the trip going, then the trip keeps going.
Webhooks will be fire for all trip status changes (i.e "processing" to "accepted" etc)
Hope that helps!
Best,
Richie
In my app, I get Lync Presence of our employees through UCWA. It works fine, but I need to knock to Lync with reportMyActivity every 3-4 minute.
I don't need to get presence info at night when employees are not at work, so I stop reportingMyActivity at the end of the working day and resume at it's beginning. Then trying to extend presence subscription, and if I get 404, I create new presence subscription. But no presence updates after those manipulations.
Is it designed to work this way? How could I avoid reportingMyActivity at night?
If you don't do reportMyActivity your Application will be drained, because assumed inactive.
I think you only have two options then:
Keep doing reportMyActivity regurarly also at night, you'll just stop extending presence subscription. Very likely you'll have to manage access token expiration too, which is normally 8 hours valid
You let the App shut down, and a complete new token acquisition, Application creation, presence subscription flow will start next morning