Braintree::UnexpectedError 422 on transactions search about braintree_ruby HOT 9 CLOSED

Thanks for the error report @xgess (I know I've corresponded with you already, but wanted to respond publicly here as well).

We are currently working to improve our advanced search and transaction searching features, as we are seeing timeouts occur occasionally on merchants with larger volume. This is the error that appears in the Ruby library when your search times out.

We are currently working to improve the performance time, but at the moment regrettably the best option is to catch this error, and retry the request.

-Matt

from braintree_ruby.

Support,

We're currently experiencing this issue three days running. Can you update us on any performance problems that you are seeing?

Jason

from braintree_ruby.

I'm also affected by this. I found the "catch this error and retry" strategy to not be viable, since many of the formerly-working search requests now fail every single time.

My current workaround is to search using id.starts_with for each of [23456789bcdfghjk] and then to merge the results locally. This is also regrettable (since it causes sixteen times as many search requests for Braintree to handle), but at least this way transaction searches actually work.

from braintree_ruby.

This is a hilarious workaround, but thank you very much @willglynn. We will implement this. I only hope @braintree and @braintreeps are embarrassed that this is what their users are reduced to.

from braintree_ruby.

The best part is, id.starts_with works for arbitrary search terms and it's completely scalable. Did a search error out? Split it into sixteenths! Wait, now three of those failed? Split them into sixteenths! The braintree gem could even do this transparently and by default -- expect a pull request. Let searches multiply like broomsticks!

Seriously though, if transaction fetches can cause timeouts, that's a problem. The API should be able to return a partial result set in a timely fashion along with whatever pagination information is needed to continue processing. DynamoDB does exactly this in order to keep both clients and servers busy. I don't know this would take a protocol revision or what -- but I do know that Braintree::Transaction.search calls that have been in production for months are now failing due to the issue described here.

from braintree_ruby.

Thanks @willglynn, much appreciated. Any feedback on the underlying issue from @braintree @braintreeps ?

from braintree_ruby.

I'm still running with my 16 sub-request approach, but if you'd prefer the normal logic with a split-things-in-half retry strategy, that's available in #56 or via your Gemfile:

gem "braintree", github: "willglynn/braintree_ruby", branch: "the_sorcerers_apprentice"

I sincerely hope no one uses this. My expectation is that Braintree will do something to actually solve this issue on a permanent basis, e.g. #55 -- but at any rate, I never want to see this error in my logs again.

from braintree_ruby.

Hey @willglynn, @jtordway, @xgess,

We're aware of this issue and are working on a fix. Specifically, we plan on two separate changes:

• Adding additional indices to these particular relations. This search query in particular is unusually slow.
• Switching to a faster XML generator.

We had planned on doing the database work today, but there's another maintenance operation going on so we've decided to hold off until Monday at the earliest. The XML generator change will likely be deployed next week.

We're also considering adjusting the way we paginate search requests to decrease the likelihood of a timeout. However, we don't plan on adding any support for partial results at this time.

We apologize for the slow response here. One of our development teams is currently working on general improvements to our search functionality, so look for more speedups in the future.

Katelyn and Lionel
Braintree Developers

from braintree_ruby.

I'm happy that the cause of this particular slowness is being addressed. That said, this is a pattern: #40, #46, #51 shows this same issue popping up every few months for different reasons. I really don't want to come back to this in March when we hit another bottleneck, and that's why I'm pushing for better timeout behavior.

from braintree_ruby.