Discarding transaction because entry was deleted

Hi All,

I have an issue with the Google Apps driver. Here is the entirety of the level 3 trace when I try to migrate an account using iManager and the Google Apps driver.

[09/07/18 09:47:09.218]:IDM4GMAIL ST:Start transaction.
[09/07/18 09:47:09.218]:IDM4GMAIL ST:Discarding transaction because entry was deleted.


The association state on the user object changes to Migrate from Processed.

If I delete the association from the user account, I can migrate the account successfully and a match is found. Any subsequent migrate results in the condition above. This is happening to multiple user objects.

Google driver is version 4.1.1.5.

Any advice appreciated.

Thanks
Adam
  • Hi Adam,

    this sound really odd. Unfortunately I don't have an answer on this. I would open an incident to get support involved.
  • Hi Adam,

    Strange thing...
    Event on subscriber channel suppose to start similarly for any driver.

    Could you increase you trace level to 5-10 and post the trace here?
  • On 9/7/2018 3:44 PM, al b wrote:
    >
    > Hi Adam,
    >
    > Strange thing...
    > Event on subscriber channel suppose to start similarly for any driver.
    >
    > Could you increase you trace level to 5-10 and post the trace here?


    The code path you seem to be hitting is an optimization item, where if
    there is an event in the cache, but the object itself is deleted, should
    you process it? Clearly not. What would processing it do? The object is
    gone. Sure you could have a use case where you might, but in general no.

    So why does the engine think it is deleted?

    Perhaps some odd kind of permission issue? (UNlikely, you would have
    gotten a 672 error in trace then).

    Maybe a higher level of trace will show more info.


  • If object really deleted, it makes sense (nothing to process), but how iManager shows association for "deleted" object?


    The association state on the user object changes to Migrate from Processed.


    >Perhaps some odd kind of permission issue? (UNlikely, you would have gotten a 672 error in trace then).
    Permission? I don't think so...
    Usually driver security equal to admin.
  • On 9/7/2018 4:44 PM, al b wrote:
    >
    > If object really deleted, it makes sense (nothing to process), but how
    > iManager shows association for "deleted" object?


    Right, the oddity of the situation.


    >>
    >> The association state on the user object changes to Migrate from
    >> Processed.

    >
    >> Perhaps some odd kind of permission issue? (UNlikely, you would have

    > gotten a 672 error in trace then).
    > Permission? I don't think so...
    > Usually driver security equal to admin.

    Usually, but not always. Worth asking, I too doubt it however.

  • On 09/07/2018 03:24 PM, Geoffrey Carman wrote:
    > On 9/7/2018 4:44 PM, al b wrote:
    >>
    >> If object really deleted, it makes sense (nothing to process), but how
    >> iManager shows association for "deleted" object?

    >
    > Right, the oddity of the situation.


    Events go through the TAO file, and are only cleaned out when they are
    processed in some way or the cache is deleted (e.g. when the driver config
    object is disabled). As a result, it is easy to think of situations where
    a now-deleted object may still be in a TAO file, but that does not match
    with the details we have been given where presumably nothing was in the
    TAO file, then ONLY a migrate of one object happened, and then the trace
    message showed up. Maybe that is what we are assuming, but is not really
    the case.

    When was the object with the association created? Not when do we think it
    was created, but what is its creation timestamp as reported by eDirectory?


    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • al b wrote:

    > If object really deleted, it makes sense (nothing to process)


    unless it's a <delete> event, maybe...? ;-)

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • I guess I would need to test to see if anything has changed with the
    latest engine, but if it is a delete sans association then I think even
    then that would make sense. There is little use in processing a delete
    for something sans association since in theory it is not linked to the
    application anyway.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below.

    If you want to send me a private message, please let me know in the
    forum as I do not use the web interface often.
  • ab wrote:

    > I guess I would need to test to see if anything has changed with the
    > latest engine, but if it is a delete sans association then I think even
    > then that would make sense. There is little use in processing a delete
    > for something sans association since in theory it is not linked to the
    > application anyway.


    Yes, unassociated deletes are useless for syncronization, no object in IDV, so
    no way to match it against an app side object. On the publisher those are
    stripped after event transform processing, IIRC, don't they even show on the
    subscriber at all? I could think of some use cases in business logic driver
    where unassociated deletes might be of interest.

    Would be great if delete events would (optionally) contain the attribute values
    of the object when it was deleted, then we'd have a chance to still match and
    delete (and clean up selectively) on the app side, too. This would make a
    really really nice enhancement (which IIRC has been requested already several
    times) - ...Tom? ;-)

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • lhaeger;2487338 wrote:
    ab wrote:

    > I guess I would need to test to see if anything has changed with the
    > latest engine, but if it is a delete sans association then I think even
    > then that would make sense. There is little use in processing a delete
    > for something sans association since in theory it is not linked to the
    > application anyway.


    Yes, unassociated deletes are useless for syncronization, no object in IDV, so
    no way to match it against an app side object. On the publisher those are
    stripped after event transform processing, IIRC, don't they even show on the
    subscriber at all? I could think of some use cases in business logic driver
    where unassociated deletes might be of interest.

    Would be great if delete events would (optionally) contain the attribute values
    of the object when it was deleted, then we'd have a chance to still match and
    delete (and clean up selectively) on the app side, too. This would make a
    really really nice enhancement (which IIRC has been requested already several
    times) - ...Tom? ;-)

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)


    <delete> events show up on the Subscriber, associated or not. They're discarded at the end of the event transform, if I recall correctly. Trace message something like "discarding delete event on unassociated object".