-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reworked pager is a breaking change in the API #207
Comments
Would you care to say more? |
Sure, sorry didn't include it before.
Now we need to do something like
|
Yeah that is strange because I wouldn't think billing info would be returning a pager. |
I'm really confused on how that would be working when I tried running the second sample using the code in master I get:
On the other hand running: try {
$billing_info = Recurly_BillingInfo::get('test2');
var_dump($billing_info->first_name);
var_dump($billing_info->last_name);
} catch (Recurly_NotFoundError $e) {
return false;
} gives me:
Could you make sure you're on the latest release and then try running the following to see what that call is actually returning? $billing_info = Recurly_BillingInfo::get('test2');
var_dump(get_class($billing_info)); |
There is an issue with the pager (but I'm seeing this with the Here's an example code snippet I have:
earlier code grabs the account_id that is linked to the local user. Previously, if there was an issue with the account_id, the However the client code calling this snippet is getting a valid
that produces:
The only thing I can think of, is this account_code is attached to a transaction that was declined, and does not exist as a full account in recurly (a transition account?). For some reason this valid account_code check is being delayed until the pager is run. As the original poster pointed out, this requires a different method of error checking by client code. Is it expected that this exception would be triggered by the pager? |
It looks like the change is, that the requested Resource object will get returned regardless of whether the given account id is correct or not and the account id is only checked when the paging is triggered. Previously the request using the account_id was done immediately on instantiation which would have thrown the error. |
yah anything that is a child of |
@nerrad thanks for better overview of the problem. This is exactly what I meant :) |
fwiw (to the library devs), it "looks" like this might be expected behaviour with the changes introduced in #195 (i.e. delay the request until the first Another possible option is for any resources involving the account_id, verify that account_id is valid before returning the resource. |
@nerrad ah, okay yeah that flow makes more sense. i'll spend some more time looking at this today. |
Hey apologies I haven't been able to get into this and I'm out of the office for the rest of the week. It'll be at the top of my list on Monday. |
so it appears (as noted in #212) that the request for the resource is now done in the |
I'm going to close this since it wasn't necessarily resolved as much as it seems everyone has moved past it. |
With the following change most of the error handling has to be reworked and rethought. Not cool.
#195
The text was updated successfully, but these errors were encountered: