Possible bug in meta backend??

[Anibal Caceres Hernando <anibal.caceres@ericsson.com>]

   Hi list,
   First of all, I want to say this is a code question, so perhaps I 
should send it to the bug or development mailing lists instead of  
sending it to this one. If this is the case, please, let me know, and I 
apologize for the mess.
   Im using OpenLDAP 2.1.25, and I've detected a strange behaviour in 
the meta backend: in some LDAP "search" operations it takes as 
candidates to send the operation some targets whose naming context has 
nothing to do with the base of the "search", then it sends to them the 
"search" operation, but they shouldn't have to receive it. The cause for 
this is in the "bind" operation previous to the "search" one: this 
operation marks its candidate targets, and this targets still remain 
marked for the next operation: the "search" one.
   I think the reason for all this is in the function 
meta_back_getconn() from the conn.c source file in the meta backend: 
This function, depending on its argument op_type marks the different 
candidate targets for each LDAP operation. In the "search" operation 
case, op_type=META_OP_ALLOW_MULTIPLE, and in this case 
meta_back_getconn() does the following "for" loop:

       for ( i = 0; i < li->ntargets; i++ ) {
           if ( i == cached
       || meta_back_is_candidate( &li->targets[ i ]->suffix, ndn ) ) {

               /*
                * The target is activated; if needed, it is
                * also init'd
                */
               int lerr = init_one_conn( conn, op,
                       li->targets[ i ],
                       &lc->conns[ i ] );
               if ( lerr != LDAP_SUCCESS ) {
              
                   /*
                    * FIXME: in case one target cannot
                    * be init'd, should the other ones
                    * be tried?
                    */
                   ( void )meta_clear_one_candidate( &lc->conns[ i ], 1 );
                   err = lerr;
                   continue;
               }
           }
       }
  
   This loop looks for every target if it is a candidate, and if it is, 
it is marked as candidate, but if the target is not a candidate, then 
nothing is done... but the list of targets is the same as in the 
previous LDAP operation, so the candidates marked for that one remain 
marked, even if they are not good candidates for the "search" 
operation... Then I think the "if " in the "for" loop must be followed 
by an "else" where the candidate is unmarked if it was marked before (I 
supposse the meta_clear_one candidate() function can be used for this).
   So, I would know what do you think about this, am I right?, or I'm 
missing something somewhere?
   Any kind of help would be appreciated. Thank you very much.
   Kind regards,

   Aníbal.