e2bc8fd Ticket 48992: Total init may fail if the pushed schema is rejected

Authored and Committed by tbordaz 7 years ago
    Ticket 48992: Total init may fail if the pushed schema is rejected
    
    Bug Description:
        In the early phase of total update (or incremental update), the supplier may send its schema.
        A supplier will send its schema to the consumer at the condition its nsSchemaCSN is greater than
        the consumer nsSchemaCSN.
        If it is the case, a 1.2.11 supplier will systematically send its schema, while a 1.3 supplier will
        check that its schema is a superset of the consumer schema before sending it.
        If a 1.2.11 supplier sends its schema and that schema is a subset of consumer one, then
        the >1.3 consumer will detect it is a subset and reject the update.
        In that case the >1.3 consumer rejects a replicated update.
    
        On the consumer side, with the fix https://fedorahosted.org/389/ticket/47788, if a
        replication operation fails, it may trigger the closure of the replication connection.
        The fix decides, based on the type of failure, if the failure can be ignored (leave the connection
        opened) or is fatal (close the connection).
        This is detected, on the consumer side, in multimaster_postop_*->process_postop->ignore_error_and_keep_going.
    
        In the current version, if a replicated update of the schema fails it return LDAP_UNWILLING_TO_PERFORM.
        This is a fatal error regarding ignore_error_and_keep_going that then close the connection
        and interrupt the total/incremental update.
    
        Note this bug can be transient as, the schema learning mechanism (on consumer) may learn from
        the received schema (even if it is rejected) and update its local schema that increase
        nsSchemaCSN. If this occur, a later replication session finding a greater nsSchemaCSN on the
        consumer side will not push the schema
    
    Fix Description:
        When the update of the schema is rejected make it not fatal, switching the returned
        code from LDAP_UNWILLING_TO_PERFORM to LDAP_CONSTRAINT_VIOLATION
    
    https://fedorahosted.org/389/ticket/48992
    
    Reviewed by: Noriko Hosoi, Ludwig Krispenz (thanks to you !)
    
    Platforms tested: 7.3
    
    Flag Day: no
    
    Doc impact: no
    
        
file modified
+18 -1