Incompatibility between 1.0.3 and 1.0.5

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Won't Fix
Affects Version/s: 1.0.2
Fix Version/s: None
Component/s: library
Security Level: Public
Labels:
None

Description

So I've been able to put together a good test case...

Here's what I did:
1. switch back to SDK 1.0.3
2. set a serialized array with 1.0.3
3. switch back to SDK 1.0.5
4. try to retrieve the serialized object with 1.0.5.
5. notice the described behavior above.

Here's a full break down:

*** REPLACE 1.0.5 with 1.0.3 and restart Apache ***

MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: ll
total 2632
drwxr-xr-x 13 root wheel 442 Sep 19 17:05 .
drwxr-xr-x 4 root wheel 136 Jun 20 17:08 ..
-rw-r--r-- 1 mssteuer wheel 173216 Mar 12 2012 apc.so
-rwxr-xr-x@ 1 mssteuer wheel 73520 Sep 19 17:06 couchbase.so
-rwxr-xr-x 1 mssteuer wheel 62812 Apr 11 12:14 couchbase.so.101
-rwxr-xr-x 1 mssteuer wheel 62836 Jul 2 15:43 couchbase.so.102
-rwxr-xr-x@ 1 root wheel 62836 Sep 19 17:05 couchbase.so.103
-rw-r--r-- 1 mssteuer wheel 67428 Sep 12 2011 memcache.so
-rw-r--r-- 1 mssteuer wheel 64120 Sep 12 2011 memcached.so
-rw-r--r-- 1 mssteuer wheel 467912 Jan 7 2012 mongo.so
-rwxr-xr-x 1 mssteuer wheel 57312 Jul 14 10:47 phpcups.so
-rw-r--r-- 1 mssteuer wheel 70148 Mar 23 17:47 ssh2.so
-rwxr-xr-x 1 root wheel 202672 Sep 19 14:59 xdebug.so
MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo cp couchbase.so couchbase.so.105
Password:
MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo cp couchbase.so.103 couchbase.so
MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo apachectl restart

*** EXECUTE PHP BELOW TO SET SERIALIZED ARRAY WITH 1.0.3 ***

echo "<pre>";
$cb = Zend_Registry::get("couchbase");

$testarray = array(
"stringvalue" => "blabla",
"intvalue" => 1234,
"arrvalue" => array(
"stringvalue" => "hello world",
"intvalue" => 98765,
),
"boolvalue" => true,
"float" => 1.239393
);

try {
$cb->set("cbtest", $testarray);
echo "Result Code:\n";
print_r($cb->getResultCode());
} catch(Exception $e) {
echo $e->getMessage();
}

*** THIS PRINTS OUT THE RESULT BELOW ***

Result Code:
0

*** TELNET TO COUCHBASE TO CONFIRM DATA IS SET ***

MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: telnet localhost 11211
Trying ::1...
Connected to localhost.
Escape character is '^]'.
get cbtest
VALUE cbtest 31 185
a:5:{s:11:"stringvalue";s:6:"blabla";s:8:"intvalue";i:1234;s:8:"arrvalue";a:2:{s:11:"stringvalue";s:11:"hello world";s:8:"intvalue";i:98765;}s:9:"boolvalue";b:1;s:5:"float";d:1.239393;}
END
quit
Connection closed by foreign host.

*** REPLACE 1.0.3 with 1.0.5 and restart Apache ***

MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo cp couchbase.so.105 couchbase.so
MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: sudo apachectl restart

*** EXECUTE PHP BELOW TO TRY AND RETRIEVE ARRAY FROM COUCHBASE, NOW USING 1.0.5 ***

echo "<pre>";
$cb = Zend_Registry::get("couchbase");

$result = $cb->get("cbtest");
print_r($result);

*** $result IS NULL AND THE "UNKNOWN PAYLOAD" AND "FAILED TO GET VALUE" WARNINGS ARE OBSERVED IN THE LOGS ***

[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP Warning: Couchbase::get(): unknown payload type in /Users/mssteuer/Documents/_Titan/XAPI/trunk/application/controllers/TestController.php on line 809
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP Stack trace:
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 1. {main}() /Users/mssteuer/Documents/_Titan/XAPI/trunk/index.php:0
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 2. Zend_Application->run() /Users/mssteuer/Documents/_Titan/XAPI/trunk/index.php:6
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 3. Zend_Application_Bootstrap_Bootstrap->run() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Application.php:366
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 4. Zend_Controller_Front->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Application/Bootstrap/Bootstrap.php:97
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 5. Zend_Controller_Dispatcher_Standard->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Front.php:954
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 6. Zend_Controller_Action->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Dispatcher/Standard.php:295
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 7. TestController->testcbAction() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Action.php:513
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 8. Couchbase->get() /Users/mssteuer/Documents/_Titan/XAPI/trunk/application/controllers/TestController.php:809
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP Warning: Couchbase::get(): Failed to get a value from server: Generic error in /Users/mssteuer/Documents/_Titan/XAPI/trunk/application/controllers/TestController.php on line 809
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP Stack trace:
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 1. {main}() /Users/mssteuer/Documents/_Titan/XAPI/trunk/index.php:0
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 2. Zend_Application->run() /Users/mssteuer/Documents/_Titan/XAPI/trunk/index.php:6
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 3. Zend_Application_Bootstrap_Bootstrap->run() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Application.php:366
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 4. Zend_Controller_Front->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Application/Bootstrap/Bootstrap.php:97
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 5. Zend_Controller_Dispatcher_Standard->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Front.php:954
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 6. Zend_Controller_Action->dispatch() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Dispatcher/Standard.php:295
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 7. TestController->testcbAction() /Users/mssteuer/Documents/_Titan/XAPI/trunk/library/Zend/Controller/Action.php:513
[Thu Sep 20 11:33:55 2012] [error] [client 127.0.0.1] PHP 8. Couchbase->get() /Users/mssteuer/Documents/_Titan/XAPI/trunk/application/controllers/TestController.php:809

*** TELNET INTO COUCHBASE AGAIN TO VERIFY DATA IS STILL PRESENT (IE. IT WASN'T A MISS) ***

MICHAEL'S MACBOOK PRO /usr/lib/php/extensions/no-debug-non-zts-20090626: telnet localhost 11211
Trying ::1...
Connected to localhost.
Escape character is '^]'.
get cbtest
VALUE cbtest 31 185
a:5:{s:11:"stringvalue";s:6:"blabla";s:8:"intvalue";i:1234;s:8:"arrvalue";a:2:{s:11:"stringvalue";s:11:"hello world";s:8:"intvalue";i:98765;}s:9:"boolvalue";b:1;s:5:"float";d:1.239393;}
END

*** THEN, I RE-SET THE SAME ARRAY USING 1.0.5 (SAME PHP CODE AS ABOVE) ***

*** GET VALUE FROM COUCHBASE TO COMPARE ***

get cbtest
VALUE cbtest 4 185
a:5:{s:11:"stringvalue";s:6:"blabla";s:8:"intvalue";i:1234;s:8:"arrvalue";a:2:{s:11:"stringvalue";s:11:"hello world";s:8:"intvalue";i:98765;}s:9:"boolvalue";b:1;s:5:"float";d:1.239393;}
END

*** CONCLUSION ***
The value looks the same, however this one has a "4" flag instead of a "31" flag above... Not sure what that means, but likely the cause of the issue.

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Michael Nitschinger added a comment - 20/Sep/12 2:09 PM

Since we're just passing it through libcouchbase and the serialized php array is the same - could it be possible that this is an incompatibility in libcouchbase?

Show

Michael Nitschinger added a comment - 20/Sep/12 2:09 PM Since we're just passing it through libcouchbase and the serialized php array is the same - could it be possible that this is an incompatibility in libcouchbase?

Hide

Permalink

Perry Krug added a comment - 20/Sep/12 3:27 PM

Anything's possible ;-) Adding Trond to have a look...

Show

Perry Krug added a comment - 20/Sep/12 3:27 PM Anything's possible ;-) Adding Trond to have a look...

Hide

Permalink

Perry Krug added a comment - 20/Sep/12 3:28 PM

Trond, can you take a look at this as well? I'm getting the libcouchbase versioning from the customer now...

Show

Perry Krug added a comment - 20/Sep/12 3:28 PM Trond, can you take a look at this as well? I'm getting the libcouchbase versioning from the customer now...

Hide

Permalink

Matt Ingenthron added a comment - 20/Sep/12 3:28 PM

Mike: can you please see if you can reproduce this and possibly identify the cause? I don't see any reason flags should have changed.

Show

Matt Ingenthron added a comment - 20/Sep/12 3:28 PM Mike: can you please see if you can reproduce this and possibly identify the cause? I don't see any reason flags should have changed.

Hide

Permalink

Perry Krug added a comment - 20/Sep/12 3:40 PM

I'm still waiting on response from the customer, but it might be that they are NOT upgrading libcouchbase between these steps...would that be required? If not, then it's definitely in the PHP library right?

Show

Perry Krug added a comment - 20/Sep/12 3:40 PM I'm still waiting on response from the customer, but it might be that they are NOT upgrading libcouchbase between these steps...would that be required? If not, then it's definitely in the PHP library right?

Hide

Permalink

Michael Jackson added a comment - 20/Sep/12 6:49 PM

For what it's worth, on the 1.0.x branch of the php-ext, git diff fc6ff727aed5190b1844eab75143cccedf52c3c0..62456429138522f15f6f42b0fad28d74a77d5cfb should show a complete diff between 1.0.3 release revision and 1.0.5.

The only part of that diff that I see that interacts with flag at all is something involving preserving order on multi-gets (changeset 37a567f4 from May 17th by Jan L.), and that's just using flag as part of a calculation rather than modifying it (and the test code above does not seem to involve a multi-get in any case). So I don't see a smoking gun per se in the diff.

Using the 1.0.3 release with cb server 1.8 and libcouchbase 1.0.4-1 on my test zone, after executing the testing code above (slight modification to directly connect instead of retrieving something from ZF's registry), I get data which seems to match the format reported for 1.0.5 above:
get cbtest
VALUE cbtest 4 185
a:5:{s:11:"stringvalue";s:6:"blabla";s:8:"intvalue";i:1234;s:8:"arrvalue";a:2:{s:11:"stringvalue";s:11:"hello world";s:8:"intvalue";i:98765;}s:9:"boolvalue";b:1;s:5:"float";d:1.239393;}
END

And the same with 1.0.5 (had to patch in one extra rev here for tsrm_ls to get it to build with my debug php, but that should not affect anything).

Show

Michael Jackson added a comment - 20/Sep/12 6:49 PM For what it's worth, on the 1.0.x branch of the php-ext, git diff fc6ff727aed5190b1844eab75143cccedf52c3c0..62456429138522f15f6f42b0fad28d74a77d5cfb should show a complete diff between 1.0.3 release revision and 1.0.5. The only part of that diff that I see that interacts with flag at all is something involving preserving order on multi-gets (changeset 37a567f4 from May 17th by Jan L.), and that's just using flag as part of a calculation rather than modifying it (and the test code above does not seem to involve a multi-get in any case). So I don't see a smoking gun per se in the diff. Using the 1.0.3 release with cb server 1.8 and libcouchbase 1.0.4-1 on my test zone, after executing the testing code above (slight modification to directly connect instead of retrieving something from ZF's registry), I get data which seems to match the format reported for 1.0.5 above: get cbtest VALUE cbtest 4 185 a:5:{s:11:"stringvalue";s:6:"blabla";s:8:"intvalue";i:1234;s:8:"arrvalue";a:2:{s:11:"stringvalue";s:11:"hello world";s:8:"intvalue";i:98765;}s:9:"boolvalue";b:1;s:5:"float";d:1.239393;} END And the same with 1.0.5 (had to patch in one extra rev here for tsrm_ls to get it to build with my debug php, but that should not affect anything).

Hide

Permalink

Michael Jackson added a comment - 20/Sep/12 6:50 PM

(I'm assigning this back to you Perry, as I'm not sure who might best be the recipient. If you need more help debugging from the php-ext side I'll be happy to help as I can.)

Show

Michael Jackson added a comment - 20/Sep/12 6:50 PM (I'm assigning this back to you Perry, as I'm not sure who might best be the recipient. If you need more help debugging from the php-ext side I'll be happy to help as I can.)

Hide

Permalink

Matt Ingenthron added a comment - 20/Sep/12 7:08 PM

Michael: to be clear, sounds like you couldn't reproduce it?

Show

Matt Ingenthron added a comment - 20/Sep/12 7:08 PM Michael: to be clear, sounds like you couldn't reproduce it?

Hide

Permalink

Matt Ingenthron added a comment - 24/Sep/12 12:57 AM

Assigning to Mike just to check to see about repro

Show

Matt Ingenthron added a comment - 24/Sep/12 12:57 AM Assigning to Mike just to check to see about repro

Hide

Permalink

Matt Ingenthron added a comment - 24/Sep/12 11:07 AM

Recent discussion indicates could not repro on a couple platforms, but Mark is going to try under valgrind. Assigning to him.

Show

Matt Ingenthron added a comment - 24/Sep/12 11:07 AM Recent discussion indicates could not repro on a couple platforms, but Mark is going to try under valgrind. Assigning to him.

Hide

Permalink

Mark Nunberg added a comment - 24/Sep/12 12:28 PM - edited

I have so far not been able to get valgrind to complain about anything (I've tested both on OS X and Linux with the ext versions specified).. except when I serialize with JSON and use compression (in which case it returns with an error before it actually sets the key on the server).

However the key to the problem is the flags value. We should never be getting 31 (first five bits set) for flags under PHP. The first five bits represent the value type, and there is no value for 31 (maximum it seems is 6).

I do see errors when doing compression (See ~~PCBC-111~~). Can you tell me if your apache is configured to use customized compression or serialization mechanisms (it seems it isn't.. but it's worthwhile checking..)

Show

Mark Nunberg added a comment - 24/Sep/12 12:28 PM - edited I have so far not been able to get valgrind to complain about anything (I've tested both on OS X and Linux with the ext versions specified).. except when I serialize with JSON and use compression (in which case it returns with an error before it actually sets the key on the server). However the key to the problem is the flags value. We should never be getting 31 (first five bits set) for flags under PHP. The first five bits represent the value type, and there is no value for 31 (maximum it seems is 6). I do see errors when doing compression (See PCBC-111 ). Can you tell me if your apache is configured to use customized compression or serialization mechanisms (it seems it isn't.. but it's worthwhile checking..)

Hide

Permalink

Perry Krug added a comment - 24/Sep/12 12:38 PM

Before into back to the customer, can you confirm that you executed the code that he provided which is supposed to reproduce the issue reliably?

Show

Perry Krug added a comment - 24/Sep/12 12:38 PM Before into back to the customer, can you confirm that you executed the code that he provided which is supposed to reproduce the issue reliably?

Hide

Permalink

Mark Nunberg added a comment - 24/Sep/12 1:48 PM - edited

I've tested this from the command line on Linux and OS X with the libcouchbase and extension versions described.. I've also tested it using apache and php5.4 on debian (I have not had the opportunity to do so on OS X).

I'm 99% sure that there is memory corruption is the culprit, but unfortunately I have not been able to reproduce this using a variety of configurations, unless he has a non-default serialization or compression enabled (which does not seem to be the case).

How is he constructing the Couchbase object, and what does it do until it reaches that point which is pasted in the code? It's quite obvious from the stack trace that this isn't a 'simple' PHP script, and that there is some more machinery involved when initially constructing the Couchbase object.

Show

Mark Nunberg added a comment - 24/Sep/12 1:48 PM - edited I've tested this from the command line on Linux and OS X with the libcouchbase and extension versions described.. I've also tested it using apache and php5.4 on debian (I have not had the opportunity to do so on OS X). I'm 99% sure that there is memory corruption is the culprit, but unfortunately I have not been able to reproduce this using a variety of configurations, unless he has a non-default serialization or compression enabled (which does not seem to be the case). How is he constructing the Couchbase object, and what does it do until it reaches that point which is pasted in the code? It's quite obvious from the stack trace that this isn't a 'simple' PHP script, and that there is some more machinery involved when initially constructing the Couchbase object.

Hide

Permalink

Perry Krug added a comment - 24/Sep/12 2:08 PM

Thanks Mordechai, asking him now.

Can you clarify for me what the expected flags are for 1.0.3 and 1.0.5 on a serialized array?

Show

Perry Krug added a comment - 24/Sep/12 2:08 PM Thanks Mordechai, asking him now. Can you clarify for me what the expected flags are for 1.0.3 and 1.0.5 on a serialized array?

Hide

Permalink

Perry Krug added a comment - 24/Sep/12 2:15 PM

From the customer:

Here's how the couchbase object is instantiated in our Zend Framework Bootstrap.php:

// couchbase
$couchbase = $this->getOption("couchbase");
if($couchbase) {
$hosts = explode(",", $couchbase["host"]);
foreach($hosts as $key => $host) {
$hosts[$key] = $host . ":" . $couchbase["port"];
}
shuffle($hosts);
$hoststring = implode(";", $hosts);
$cb = new Couchbase($hoststring, $couchbase['username'], $couchbase['password'], $couchbase['bucket']);
Zend_Registry::set("couchbase", $cb);
} else {
Zend_Registry::set("couchbase", null);
}

(the couchbase ini config below):

couchbase.host = "ec2-23-23-179-50.compute-1.amazonaws.com,ec2-23-23-179-51.compute-1.amazonaws.com,ec2-23-23-179-52.compute-1.amazonaws.com,ec2-23-21-229-162.compute-1.amazonaws.com,ec2-23-21-229-186.compute-1.amazonaws.com,ec2-23-21-229-188.compute-1.amazonaws.com"
couchbase.port = 8091
couchbase.username = ******
couchbase.password = ****************
couchbase.bucket = default
----------------------

Is that enough?

Show

Perry Krug added a comment - 24/Sep/12 2:15 PM From the customer: Here's how the couchbase object is instantiated in our Zend Framework Bootstrap.php: // couchbase $couchbase = $this->getOption("couchbase"); if($couchbase) { $hosts = explode(",", $couchbase["host"]); foreach($hosts as $key => $host) { $hosts[$key] = $host . ":" . $couchbase["port"]; } shuffle($hosts); $hoststring = implode(";", $hosts); $cb = new Couchbase($hoststring, $couchbase['username'], $couchbase['password'], $couchbase['bucket']); Zend_Registry::set("couchbase", $cb); } else { Zend_Registry::set("couchbase", null); } (the couchbase ini config below): couchbase.host = "ec2-23-23-179-50.compute-1.amazonaws.com,ec2-23-23-179-51.compute-1.amazonaws.com,ec2-23-23-179-52.compute-1.amazonaws.com,ec2-23-21-229-162.compute-1.amazonaws.com,ec2-23-21-229-186.compute-1.amazonaws.com,ec2-23-21-229-188.compute-1.amazonaws.com" couchbase.port = 8091 couchbase.username = ****** couchbase.password = **************** couchbase.bucket = default ---------------------- Is that enough?

Hide

Permalink

Perry Krug added a comment - 24/Sep/12 2:35 PM

Screenshot of his PHP info: http://support.couchbase.com/attachments/token/njmhbuo4i63mlop/?name=Screen+Shot+2012-09-24+at+12.11.52+PM.png

Show

Perry Krug added a comment - 24/Sep/12 2:35 PM Screenshot of his PHP info: http://support.couchbase.com/attachments/token/njmhbuo4i63mlop/?name=Screen+Shot+2012-09-24+at+12.11.52+PM.png

Hide

Permalink

Perry Krug added a comment - 24/Sep/12 2:35 PM

Note the 1.0.2...is that how the version was reported?

Show

Perry Krug added a comment - 24/Sep/12 2:35 PM Note the 1.0.2...is that how the version was reported?

Hide

Permalink

Mark Nunberg added a comment - 24/Sep/12 2:48 PM

Then he is in fact using v1.0.2, not v1.0.3 as originally claimed.

Quickly looking at the commit for 1.0.3 (i.e. changes between 1.0.2 and 1.0.3) I see significant modification of the flag values. Basically 1.0.3 will set the flag to PHP's internal type code, whereas 1.0.3 and onwards use pecl-memcached style extension flags. See ~~PCBC-61~~.

In short, the versions are incompatible, and 1.0.2 is broken. Unfortunately there is no nice way to have a mixed-mode client setting (i the user is daring enough, he can copy the old flag code from 1.0.2+ and paste it in the newer version..) and the design of the old flag mechanism was inherently flawed (and not compatible with memcached either).

Show

Mark Nunberg added a comment - 24/Sep/12 2:48 PM Then he is in fact using v1.0.2, not v1.0.3 as originally claimed. Quickly looking at the commit for 1.0.3 (i.e. changes between 1.0.2 and 1.0.3) I see significant modification of the flag values. Basically 1.0.3 will set the flag to PHP's internal type code, whereas 1.0.3 and onwards use pecl-memcached style extension flags. See PCBC-61 . In short, the versions are incompatible, and 1.0.2 is broken. Unfortunately there is no nice way to have a mixed-mode client setting (i the user is daring enough, he can copy the old flag code from 1.0.2+ and paste it in the newer version..) and the design of the old flag mechanism was inherently flawed (and not compatible with memcached either).

Hide

Permalink

Perry Krug added a comment - 24/Sep/12 3:45 PM

Thanks Mordechai, I'm checking with the customer again. Is there any sort of addition we could make to 1.0.5+ to make it backwards compatible with 1.0.2?

Show

Perry Krug added a comment - 24/Sep/12 3:45 PM Thanks Mordechai, I'm checking with the customer again. Is there any sort of addition we could make to 1.0.5+ to make it backwards compatible with 1.0.2?

Hide

Permalink

Perry Krug added a comment - 24/Sep/12 4:02 PM

Okay, we can stand down on this...customer was only testing on a dev environment which was 1.0.2. All prod is 1.0.3 so we shouldn't have any issue.

Thanks for everyone's help.

Show

Perry Krug added a comment - 24/Sep/12 4:02 PM Okay, we can stand down on this...customer was only testing on a dev environment which was 1.0.2. All prod is 1.0.3 so we shouldn't have any issue. Thanks for everyone's help.

Hide

Permalink

Mark Nunberg added a comment - 24/Sep/12 4:03 PM

It can be possible to some extent. Let me write a simple patch against 1.0.5 and check it out. I'm not sure if we'd want to place it directly in 1.0.5.. but that is more a question for Matt.

Show

Mark Nunberg added a comment - 24/Sep/12 4:03 PM It can be possible to some extent. Let me write a simple patch against 1.0.5 and check it out. I'm not sure if we'd want to place it directly in 1.0.5.. but that is more a question for Matt.

Hide

Permalink

Matt Ingenthron added a comment - 24/Sep/12 5:31 PM

Closing this, as 1.0.2 is long ago and this affects primarily a dev environment which can (and should) upgrade.

Show

Matt Ingenthron added a comment - 24/Sep/12 5:31 PM Closing this, as 1.0.2 is long ago and this affects primarily a dev environment which can (and should) upgrade.

People

Assignee:

Matt Ingenthron

Reporter:

Perry Krug

Vote (0)

Watch (2)

Dates

Created:

20/Sep/12 1:51 PM

Updated:

24/Sep/12 5:31 PM

Resolved:

24/Sep/12 5:30 PM

Agile

View on Board