Heads up, a priori, there is a bootstrap step missing.
@olasd told me it's possible we need to start an incremental one first (thanks).

Indeed, it does more things but stop real soon (only 213 origins are found, the main bitbucket instance is quite larger than that).

There are some more analysis to do.

@douardda As discussed orally, as i was unsure it ran at the time, I checked and yes.
We have data in the swh-lister db (~214 entries listed in table bitbucket_repo).
It ran around 2017-06-28 13:13:30.077108 (most probably prior to the scheduler existence).

So i believe the full lister implementation never worked (looks like a copy/paste from github lister's, db_partition_indice implem. cannot work here).
The incremental one is mostly ok though (as already mentioned, it's not complete).

But somehow, it's stopped because the supposed next link returned by api call is not found after a certain iteration.

Tryout within docker gives the following log output:

...06-20 17:45:27,466: INFO/ForkPoolWorker-1] stopping after index 2008-09-07T21:41:16.564922+00:00, no next link found

Nevertheless, executing that query manually though (through a top-level), i do have a data output with a 'next' link...
I'm wondering if it's not a bitbucket api limitation on their side. A kind of rate limit implementation.

In [64]: url4='https://api.bitbucket.org/2.0/repositories?after=2008-09-07T21:41:16.564922+00:00'

In [65]: d4 = requests.get(url4)

In [66]: d4
Out[66]: <Response [200]>

In [67]: data = d4.json()

In [68]: data.keys()
Out[68]: dict_keys(['pagelen', 'values', 'next'])

In [69]: data['next']
Out[69]: 'https://api.bitbucket.org/2.0/repositories?after=2008-09-07T21%3A41%3A16.564922%2B00%3A00'

So i believe the full lister implementation never worked (looks like a copy/paste from github lister's, db_partition_indice implem. cannot work here).

Thinking further, that might not be the case as the bitbucket lister was amongst the first lister with the current scaffolding (if not even the first?).
In any case, still no longer works today. So might be time to fix it or remove it altogether (if unused and fix solely the incremental one).

In any case, still no longer works today. So might be time to fix it or remove it altogether (if unused and fix solely the incremental one).

After discussing with @olasd, it's not a good idea to remove it.
The full lister is here to fill in the holes of the incremental lister.
So definitely, fixing it is the right way to go.

Taking a look further with olasd, we might have one way to fix the full lister.
I'll open a diff to fix that (D1629)

I'm wondering if it's not a bitbucket api limitation on their side. A kind of rate limit implementation.

Nope, i was wrong again.
Taking an even closer look, it turns out that the listing stops because the last 2 api requests, even though differents, give the same next link (same next pagination index).
This enters the termination condition check we have in the lister, thus stopping the iteration...

So a priori, not a regression on our part which is always a good thing to know \m/.

I'll open a diff to try and improve the pagination behavior for that peculiar case (D1634).