Lists/members/create_all not adding people to a list


#1

Hi.

We have recently noticed that our calls to the lists/members/create_all passing several comma separated list is ignoring most of the user ids passed to the endpoint.

We have seen this behaviour both in our app (using the api) and in the apigee console. Here’s an example:

user_id: 2890020569,1456394982,2873784815,2625116151,2864623095,2879864339,1874923808,2828739661,520675155,2483032419,2901081005,1514316733,582707933

list_id: 189509955
slug: posttest

This test list has already only 28 users. A properly authenticated call to the endpoint lists/members/create_all would return the following json:

{ id: 189509955,
  id_str: '189509955',
  name: 'PostTest',
  uri: '/JuandelosMuert1/lists/posttest',
  subscriber_count: 0,
  member_count: 28,
  mode: 'public',
  description: ' (generada con http://SocialBro.com)',
  slug: 'posttest',
  full_name: '@JuandelosMuert1/posttest',
  created_at: 'Wed Jan 21 15:56:30 +0000 2015',
  following: true,
  user: 
   { id: 890831431,
     id_str: '890831431',
     name: 'Juan de los Muertos',
     screen_name: 'JuandelosMuert1',
     location: '',
     profile_location: null,
     description: '',
     url: null,
     entities: { description: [Object] },
     protected: false,
     followers_count: 5,
     friends_count: 2,
     listed_count: 1,
     created_at: 'Fri Oct 19 11:48:03 +0000 2012',
     favourites_count: 47,
     utc_offset: 3600,
     time_zone: 'Madrid',
     geo_enabled: false,
     verified: false,
     statuses_count: 546,
     lang: 'es',
     contributors_enabled: false,
     is_translator: false,
     is_translation_enabled: false,
     profile_background_color: 'C0DEED',
     profile_background_image_url: 'http://abs.twimg.com/images/themes/theme1/bg.png',
     profile_background_image_url_https: 'https://abs.twimg.com/images/themes/theme1/bg.png',
     profile_background_tile: false,
     profile_image_url: 'http://pbs.twimg.com/profile_images/3564504868/eef6dc8f8efc6a505e3392ac9187b860_normal.jpeg',
     profile_image_url_https: 'https://pbs.twimg.com/profile_images/3564504868/eef6dc8f8efc6a505e3392ac9187b860_normal.jpeg',
     profile_link_color: '0084B4',
     profile_sidebar_border_color: 'C0DEED',
     profile_sidebar_fill_color: 'DDEEF6',
     profile_text_color: '333333',
     profile_use_background_image: true,
     default_profile: true,
     default_profile_image: false,
     following: false,
     follow_request_sent: false,
     notifications: false } }

Meaning NO user of the batch has been added. In fact, that list with only 28 members is the result of a process where we progressively add users to a list in batches of 20 users. From a total set of 3500-ish users, the process ended having added only 28, which means that most of the calls end up not adding anyone except from a few.

If you take the ids of the batch, none of those users is banned or non-existent, and the call is successful.
We have changed nothing on our side so it looks like maybe there’s a recent issue about this.

Thanks for your help.


Nondeterminstic behavior for lists/members/create_all
#2

Sorry for the delay. I attempted the following:

1.) Create a list
2.) Added to the list the aforementioned 13 members, and it returned:

{
“id”: 226324146,
“id_str”: “226324146”,
“name”: “testlist”,
“uri”: “/rchoi/lists/testlist”,
“subscriber_count”: 0,
** “member_count”: 13,**

2.) Added to the list the same IDs and got:

{
“id”: 226324146,
“id_str”: “226324146”,
“name”: “testlist”,
“uri”: “/rchoi/lists/testlist”,
“subscriber_count”: 0,
** “member_count”: 26,**

3.) Added to the list again with only 12 and got:

{
“id”: 226324146,
“id_str”: “226324146”,
“name”: “testlist”,
“uri”: “/rchoi/lists/testlist”,
“subscriber_count”: 0,
** “member_count”: 25,**

In all cases, the users remains 13; no other ones are modified. I agree that the return message is counting incorrectly, and I’ll create a ticket for that.

I’m unfortunately not able to test the 3500 scenario; do you happen to be seeing any rate limiting or other error messages in any of the responses?


#3

Hi Ryan

Thanks for looking into this.

Unfortunately, I’m afraid there’s more to this issue than just the count (although that was something I hadn’t noticed before). In our experience, some of the batches may succeed, mainly the first being sent. It’s after some batches that most of them start failing and behaving weird, as if some kind of threshold or trigger caused it.

There are other threads here where people are describing exactly the same issue. This one has a lot of info coming from different developers: Nondeterminstic behavior for lists/members/create_all
I don’t know if you have checked these, let me know if, after checking that thread, you need any more info and I may be able to provide you with some logs and / or datasets bigger thatn 13 users (I only provided that batch as an example here).

Thanks for your help @rchoi