The CDT list set operation returned parameter error sometimes

cdt

#1

By the document, If an index is out of bounds, a parameter error will be returned. Should the ListOperation.set return error or not while index is larger than the list size?

I tried this API , under some circumstances it may return parameter error. Not sure why sometimes it may be failed.


#2

I found the error log on the server side as below:

Feb 25 2016 10:44:08 GMT: WARNING (particle): (particle_list.c::1445) packed_list_set() as_packed_list_remove failed with ret=-4
Feb 25 2016 10:44:08 GMT: WARNING (particle): (particle_list.c::1729) cdt_process_state_packed_list_modify_optype() SET failed
Feb 25 2016 10:44:08 GMT: WARNING (rw): (thr_rw.c::4070) {youzan} write_local: failed as_bin_cdt_alloc_modify_from_client() <Digest>:0x999a4186d7d983314a3fb37a28e32ddf924c07a9
Feb 25 2016 10:44:08 GMT: WARNING (particle): (particle_list.c::1975) OP_LIST_GET_RANGE: invalid list element at index 118
Feb 25 2016 10:44:08 GMT: WARNING (rw): (thr_rw.c::6065) {youzan} read_local: failed as_bin_cdt_read_from_client() <Digest>:0x999a4186d7d983314a3fb37a28e32ddf924c07a9

It seems the list is corrupt at the index 118. Is it the known issue and how to fix this?

I tried several times with the same data and it is always happening at this key.


#3

If your list has N elements, applying SET on an index > N is not considered out of bounds. If you were using negative index notation however, index < -N is considered out of bounds.

GET (and any read op) is different in that index > N is considered out of bounds.


#4

As for your error. It looks like an element is corrupted. There have been fixes for list corruptions in version 3.7.4 so it is worth checking to see if your issue is already fixed.

Otherwise reply with what your operations look like.


#5

Thanks for the explanation for the out of bound.

About the error, I tried the version 3.7.4 and found the issue is gone. Likely it has been fixed already, Thanks~


#6

With the newest 3.7.4, some situation may cause the same issue. We found when the value containing the unicode string may cause this issue.

Something like this:

 (msgEntity:{type=test, content={"sent_at":"1455011636","news":[{"link":"https:\/\/wap.test.com\/v2\/test\/test?alias=ZXJyZGhSLDZqNzVueA","title":"\u9664\u5915\u591c\u62a2\u7ea2\u5305\u544a\u8bc9\u6211\u4eec\uff1a\u53ea\u6709\u656c\u4e1a\uff0c\u624d\u6709\u7ea2\u5305\uff1b\u53ea\u6709\u656c\u4e1a\uff0c\u624d\u6709\u524d\u9014\uff01","desc":"","cover":"http:\/\/dn-test.me\/upload_files\/2016\/02\/09\/Fh-06KETrJcl_JMIfAI7zWEUgpfy.gif"}]}}),(sendTime:{seconds=1455011642, nanos=18000000}))

#7

My fault, it is happening because it is updated from old version and maybe the list value was corrupted. I can insert without problem with a whole fresh data.