Woocommerce order.updated webhook not always triggered - hook-woocommerce

I am struggling with some weird issue, maybe someone has an idea how to resolve it / Automate a workaround.
When a new order is placed, woocommerce triggers order.updated hooks.
Order that has not yet been paid has status pending:
screenshot pending order
After the order has been paid, an API call is sent with status processing
screenshot processing order
The API on the receiver side only responds to messages with status processing.
Issue:
Sometimes it happens (+/- 1 time on 30 orders) that the 2nd message (status processing) is not triggered automatically.
Workaround: Open order manually and click update. This triggers order.updated api with status processing.
Unfortunately i am not able to catch the scenario when this happens.
As a solution I thought of some script to "retry" open orders in status processing and then put cron on it to execute every hour? I am not a developer and will not be able to create it myself..
But maybe there are other / better ideas how to resolve it?
Thank a lot!

Related

Alamofire for iOS Track Number of Active Download Requests

I am trying to find a simple way to display a counter in the status bar of my app that shows the current number of active downloads using the AlamoFire package in the default session.
We have both data downloads and image/document downloads that occur sumiltainiously. I cannot find a solution as all my searches either return information about the authtoken interceptor or how to cancel request. I have tried using snippets from both of those solutions but cannot get the function to return more than 1 active request when I know there is actually 3 - 25 active requests in process.
Currently I am using a notification that I created to says a request has started and adding 1 to the counter. I am then also sending a notification when a request completes either successful or unsuccessful that subtracts 1 from the counter. The issue comes when the app is placed in the background and/or there was a request that was retried by the interceptor causing the count to go negative or get stuck being positive.
I have handled the uploads by using my uploads queue and simply retrieving the count. I do not have a similar queue for downloads as the history of them is not as important to us and we don't have start, in process, and completed triggers for them like we do uploads.

New Twilio alarm generated with every call - no errors or warnings in the logs

I've turned on one of the new Beta Alarms for all warnings and errors. The alarm is triggered every time there's an incoming call (I usually get 2 when the call initiates and two more when the call completes), however there are no errors or warnings shown in the error logs. Is this expected behavior? On one hand it's been handy because we've had one caller who doesn't respond to the prompts and just hangs on, chewing up minutes. On the other hand, it's annoying to get these when calls are being processed normally.
Looks like a bug, I suggest opening a ticket with Twilio support to investigate. If the Alarm event says, Any Warning or Error but the webhook generated says, Log info, something seems off.

Twilio Studio Flow - Flow execution stuck due to flow not transitioning

Twilio Studio Flow is having a problem with transitioning to the next widget when a user disconnects the phone. This causes the phone number used to not receive further calls as Twilio keeps the execution alive with that phone number. This is causing massive issues!
To explain the scenario/problem - When Twilio successfully calls the user and the user answers to start going through the flow, the user disconnects the call towards the end of the flow, after the hangup event is triggered on the widget, the flow manages to move through a couple of widgets after this, however stops on a widget which causes the execution to get stuck as the call is not being disconnected I assume. The widget it get's stuck on is a Say/Play and has an autocomplete which should move to the hangup function.
Here are some images to help with my explanation...
Image of the logs:
Image of the widget which the call is stuck on:
Best approach for this is to open a support ticket for them to investigate further. Twilio does have a programmatic way of ending an execution here but ideally it wouldn’t be in a stuck state to begin with.
Update an Execution
Understanding and Avoiding Stuck Executions in Twilio Studio

Why did my cloud run eventarc trigger lose it's topic subscription?

I have a cloud run service deployed, with an eventarc trigger which creates a pubsub topic behind the scenes, to which the trigger is subscribed.
Recently to my horror I noticed the trigger was not being invoked anymore. Looking further I noticed there were 0 subscriptions to the pubsub topic. I went to the cloud run service console and the trigger still existed, so why no subscription to the topic?
I have redeployed the service multiple times before, and the subscription has never disappeared like this. Deleting and re-creating the trigger brought back the subscription, however now I lost all my messages. :-(
Can anyone explain how this could happen, and if it does happen again, how I can re-enable the subscription without re-creating the trigger and thus losing all my pubsub messages?
Thank you very much.
Pub/Sub subscriptions created by Eventarc triggers should definitely not expire. If you see this again, please open a bug with details: https://cloud.google.com/support/docs/issue-trackers
I received this message from the engineering team:
"As of May 3rd, pubsub subscriptions created by creating an Eventarc trigger are set to never expire. Previously, they had a default expiration of 30 days of inactivity.
It sounds like what the customer is experiencing is consistent with that. What happened was there were 30 days of inactivity and the subscription expired.
The workaround at the moment would be to create a new trigger."

How do bring my App "up to date" - background fetch?

I am looking for a good way how to make my app "upToDate". These are my requirements:
I have an RESTful Webservice, with tasks for different users. Every user has an iOS App, which should get automatically updated when the Server/Service assigned a task to that User.
So first ill created a manuall "Sync" Button, which checks for new Tasks. Fetches the data with Alamofire, and updated the UI.
But, my goal is automatically sync if there are new tasks.
So, ill guess there are 2 different ways to solve that:
1. Make a Background Fetch (with a NStimer?) every xx Minutes and check if there are new tasks.
After checking that tutorial here:
http://www.raywenderlich.com/92428/background-modes-ios-swift-tutorial i am not sure if a background fetch is a good way to solve that. In that case the App uses an scheduler, to check once for new updates, and not every xx minutes.
So in my case i would create an NStimer in the AppDelegate (maybe in applicationDidEnterBackground) and check every xx minutes for new data (but when there are 3 days not any new task, that would be unnecessary battery consumption, or?)
2. Using Push Notifications.
My other idea is to use Push Notifications, so when there is a new task, ill send a Push Notification an manually start the sync. In my opinion that would use less battery, because he will only start the sync when there is a new task available.
Generaly Questions about using Background Services
So ok, if the user finished the task, some data should be automatically uploaded to the server. Normally not a problem, with the manual sync ill check if there is something to upload. But, what if, when there is no internet connection (ill check if before uploading) - and the user do not press on "manual sync".
So i would prefer to check in my "Background Service" if ill got an Internet connection, and if yes - start uploading some data.
Ill know this is not a specific question, but ill think there are lots of users who have the same requirements and it would be great if someone can help me out whats the best way to solve that in the best and practical way.
Thanks in advance!
Background updates sound wonderful until you realise that Apple throttles them heavily: you can ask to be updated as frequently as possible, but iOS decides what that value actually means based on how often users open your app and when they do so. Apple considers background updates the kind of thing that should happen just before a user opens your app so the latest content is right there, rather than something that runs proactively in the background.
Your push notification solution is a better one, particularly if you use CloudKit to subscribe to record change events using CKSubscription and CKNotificationInfo. If you do this you'll automatically get push messages in your app, so you can get what you want with very little work. You can read my tutorial for more information on subscribing to CloudKit to get push messages.

Resources