If site has over 60,xxx users, Subscriptions break
geerlingguy - June 25, 2009 - 20:32
| Project: | lm_paypal |
| Version: | 6.x-2.x-dev |
| Component: | LM Paypal Subscriptions |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
I'm getting this error in the watchdog table whenever a new subscription is paid for via PayPal:
IPN subscribing unknown uid, ignored: (insert number here)
I'm wondering, is the 'uid' supposed to be the actual user id of the user who subscribed from the Drupal site? If so, the numbers are not matching. I have over 70,000 users on my site, and I wonder if that might cause some sort of bug in the LM Paypal subscriptions...
#1
Read this post directly below yours. http://drupal.org/node/500434
There is a UID limit for which you seem to be proving the limit.
I am getting close to publishing and looking through all documentation of modules for any potential future issues.
#2
D'oh! I didn't ever notice that. I guess I have proven the limit, then. All the subscribers are not being allowed to subscribe, because the IPNs aren't matching their UID's. Is there any possible way I can get this fixed? Right now, I have to keep checking for errors, and manually editing users who are subscribing. It's quite a pain...
If you could even just point me in the right direction, that'd be great. I think we'd be willing to offer a bounty, if it comes to that.
#3
I just happened to come across the note that day I posted. I was hoping to get a response before we published the site within the next 3 weeks. I'm not sure why that magic number is there either. Seems the developers are not actively supporting at the moment because they are busy on other projects from what I've read. I'm not sure how to get around it but still looking at the code. I'm curious to know first if it is a module limit or paypal limit. If it is a module limit then there may be a way around it. If it is a paypal limit then that may be a show stopper for me and paypal but don't want to speculate until we learn more. I'll keep looking and respond as soon as I find something definitive.
#4
The limit is due to the old way in which two numbers - the node-id and and the user-id are combined into a 32-bit number - by limiting them to 16 bits each. This is not an issue in the new branch of LM Paypal, but remains in the original/legacy codebase. It is not a paypal limitation - in fact paypal doesn't know anything about this field at all, it just sends it back to Drupal as-is.
#5
So if I upgrade to 2.0 alpha 1, this problem should disappear? Or should I grab the -dev release. I'd like to roll this out live a.s.a.p., as I'm manually adding the 'subscriber' roll to anyone who subscribes right now.
#6
Don't do that - the new release is far from production ready. I'm afraid there is no short-term fix for that issue. You could change the code, but that may break existing IPNs (I would have to check code etc)
#7
@ lyricnz - ah well. Might you be interested in a bounty to fix this issue, or to complete more dev on the updated version? I think I might be able to get a small budget for that :-)
#8
I can help with testing but not able to help with any funding. I'm looking to release in about 2-4 weeks but may not encounter an issue until a year or two even with legacy version.
#9
Just updating the title to make it more sensible.
#10
It would seem that there's a problem with the "custom" IPN field being matched from the lm_paypal_subscriptions table to the "custom" field in the ipn table.
I noticed this code tacked onto the end of the core lm_paypal.module:
<?php/**
* Extract data from the 'custom' field in an IPN. The old way LM Paypal did it
* was by bit-packing into a 32-bit integer. The new way is PHP serialized data.
*
* @return array
* An associative array with at least 'uid' and 'other'
*/
function lm_paypal_unpack_ipn_custom($ipn) {
if ($ipn) {
if (is_int($ipn->custom)) {
// Old bit-packing format for 'custom'. The uid is in the bottom of 'custom'
return array('uid' => $ipn->custom & 0xFFFF, 'other' => ($ipn->custom >> 16) & 0xFFFF);
}
else {
// New serialized data
return @unserialize($ipn->custom); // In case the passed string is not unserializeable, FALSE is returned and E_NOTICE is issued.
}
}
else {
// Not set
return array();
}
}
?>
And I'm guessing you're still working on this IPN system - it's passing through the completed payments properly, but the subscriptions are never being set up after the IPN is received and validated. (My IPN table has 8 records in it, all with the proper uid values and "custom" field information, but nothing's being added to the subscriptions table).
I might go back to 1.x until this is fixed; I am definitely willing to help!
#11
We haven't had time to work in 6.x-2.x recently, but it's totally possible there's a bug in this area. What does $ipn->custom look like, for your operations?
#12
subscribing