I've build an iOS app that uses the iOS SquarePointOfSaleSDK which returns me a transaction Id and nothing more. Since I need more information about the payment (e.g: method, how many tenders, etc.) I'm calling the RetrieveTransaction Connect API v2 service immediately when I receive the transaction id from the Square POS app and this normally works, but sometimes I get the error described below.
{"errors":[{"category":"INVALID_REQUEST_ERROR","code":"NOT_FOUND","detail":"Location `XXXXXXXX` does not have a transaction with ID `YYYYYYYYYYYYYYYYYYYY`.","field":"transaction_id"}]}
When this transaction actually exists in this location.
I'm guessing the transaction, sometimes, is not available for API actions that fast, but I couldn't find anything in the documentation about this, I'd really appreciate any help or guidance in this, thank you in advance.
Yes, there can sometimes be a small delay between Charge and the transaction actually being retrievable. Unfortunately I'm not sure on how long the delay can be but I'll make sure this gets added to our documentation.
For now, I would suggest that if the error occurs, just to have the code attempt the RetrieveTransaction call again, perhaps looping until it's available. You should probably also include a way to get out of it (after X time or something), just to prevent the rare possibility of an endless loop.
Related
I'm new to NServiceBus, so maybe I'm asking something pretty silly here, but is there a way to make NServiceBus not stop sending any messages that are sent in response to a message whose handler fails?
Let me explain with a simple example.
Suppose I have an OrderPaidEvent that has a handler that does the following:
Look for the customer
Start a DB transaction
Update the customer to a good customer
Send an CustomerUpgradedToGoodCustomerEvent message
Commit the DB transaction
Fairly straightforward, all is well in the world. Now a few months later someone else figures that an email would be nice when an order is paid and thus adds another handler to the OrderPaidEvent to send an email.
Unfortunately, now whenever the mailserver has an issue, this second handler will fail with an error which will however prevent the original CustomerUpgradedToGoodCustomerEvent message from being sent (step 4). But because the DB transaction was already committed (step 5) the customer has already been upgraded to a good customer in the database.
This means that even if the OrderPaidEvent handler is retried the customer no longer changes and thus the CustomerUpgradedToGoodCustomerEvent message is never sent. Worse yet, this is all because of a change to the code that has nothing to do with the original message handler and will thus be difficult to detect.
This seems like a massive flaw and since I'm new to this I'm certain there's something I'm doing wrong, but I can't seem to figure out what it is.
Any help from you fine people would be great.
Thanks in advance.
How about breaking down your procedural code into separate handlers?
Thereafter each logical operation will either be done or will not be done based on successful completion of each granular task.
If you add a Saga to the mix then you can make business decisions based on the completed steps in your Saga.
Also maybe read more about transactions and NServiceBus here
First of all I would send out the CustomerUpgradedToGoodCustomerEvent after the commit. At that point you are sure that the event actually took place.
And in response to your question: You could handle the email in some 'SendEmail' command that is raised after the db commit and before the event is published. If that command fails it will not hurt the handling of the OrderPaid event. When mail is up again, the command can be retried and handled normally.
I've been trying to solve this issue for a few weeks now. The issue revolves around a Cordova plugin called cordova-plugin-playlist that utilizes AVQueuePlayer.
The issue is that when a large number of tracks (30+) are added, several of the tracks time out when attempting to buffer. Because of this, AVQueuePlayer is only able to play some of the tracks that I'm attempting to load (it just skips the error tracks when attempting to play them). The tracks that time out are always random. Attempting to add only the first 15 or so tracks from the same list succeeds, so it appears to be directly related to the number of tracks being added.
What I've figured out by logging the requests to my server is that AVQueuePlayer is attempting to buffer all of the tracks all at once, rather than buffering only the current and maybe the next track. When there are 20 or fewer tracks, all of the tracks load and play fine, but when there are 30 or more, the request seems to be too much to handle, and the requests begin to time out before some of the tracks are able to load.
All of the tracks are added via AVQueuePlayer's insertItem method. Is there something about this method that causes a track to immediately begin buffering as soon as it is added? Is there a way to prevent this behavior? I would like only the current and next tracks to buffer. Or am I fundamentally misunderstanding something? Thanks in advance for all your help!
I've solved the issue. In case it helps anyone, it wasn't an issue with AVQueuePlayer itself, but rather with the subclass AVBidirectionalQueuePlayer included with the cordova-plugin-playlist plugin. The issue lies within the overridden insertItem method in AVBidirectionQueuePlayer.m (line 217 in my case).
if (CMTIME_IS_NUMERIC(item.duration)) {
NSLog(#"duration: %5.2f", (double) CMTimeGetSeconds(item.duration));
if (CMTimeCompare(_estimatedDuration, kCMTimeZero) == 0)
_estimatedDuration = item.duration;
else
_estimatedDuration = CMTimeAdd(_estimatedDuration, item.duration);
}
The item.duration call triggers the track to load (and it's called each time a track is added, so it triggers ALL of the tracks to load), which is fine for a smaller number of tracks, but with 30+ tracks, some an hour or longer, my server was overloaded and the requests were timing out.
In my particular instance, it seems that item.duration is never NUMERIC here anyway, so my solution was to comment out the IF statement entirely.
I’m developing a small game where the player owns droids used to perform some automated actions. The easiest example is giving an order to a droid to send him at a specific position. Basically, the users gives it a position and the droid goes there. I’m already using a lot Azure app function and I’d like to use them to make the droid moves.
On the top of my head, I thought about making one function that would trigger every minute, fetch all the droid that need to move then make them move.
The issue with this approach is that if the game is popular, there could be hundreds of droids and I have to ensure that the function execution time stays below the minute.
I thought about just retrieving all droids that needs to move then for each of them calling a Azure app function via its URL to make it execute for this particular droid. In my head, it would parallelize the execution a bit but I’m not sure I’m correct.
I also have to think about using sql transaction or not in order to be sure not to create deadlocks.
The final question would be « how to handle recurring treatment of potentially large amount of data and ensure that it stays below the minute ? »
Thanks for your advice
Typically, you handle such scenarios with queues. Each order becomes a queue message, and then Azure Function is triggered by it and processes the order. It can and will scale based on the amount of messages in the queue.
If your logic still requires timer-based processing, the timer should be as lean as possible, e.g. send the queue messages to a queue which would do the real work.
I have encountered a problem, that Google notifications quite often do not arrive without any apparent reason. This makes them almost unusable for me, since it seems like they appear just in 60% of cases.
Is this common? Should I stop relying on them and set up a one minute scheduler for syncing event insted?
Thanks for your opinion
AFAIK, notification is not 100% reliable also stated in the document. As an alternative you could use Incremental sync:
Incremental sync allows you to retrieve all the resources that have been modified since the last sync request. To do this, you need to perform a list request with your most recent sync token specified in the syncToken field. Keep in mind that the result will always contain deleted entries, so that the clients get the chance to remove them from storage.
Hope this helps.
I have a WF4 Service with a flowchart as the root activity. It contains multiple correlated receive activites and decision branching to step through an approval process. The receive activities work perfectly until I try and use one as the trigger for a pick branch.
I am running tracking so can see that the receive is opened and in the persistance I can see the associated bookmark. When I send a client message with the receive type it does not trigger. I have a delay pick branch that fires OK but then the subsequent receive also does not work.
I have checked these receive activities individually and they work OK when not used as the pick trigger. I have tried the pick within a Sequence and a While but no difference.
I cannot see any difference between my implementation and may examples on the web. Am I missing something extra required when the receive is encapsulated by a pick branch?
There is nothing special about a PickBranch trigger that would cause a receive to behave differently so I suspect it is something with the Receive itself. What kind of errors are you seeing at the client application?