Taskflow process executor sending dup task notifications

[Joshua Harlow]

When running the following:

https://gist.github.com/harlowja/5bbf3e2bcd0eace7e1d2

The output is:

https://gist.github.com/harlowja/072945a37b71c5624ac7

There is one to many 'update_progress' 0.5 in that output.

[Joshua Harlow (harlowja)]

Trace log levels of the above program (so that the dups can be seen being sent).

https://gist.githubusercontent.com/harlowja/ff1e4e8e699eab4208a7/raw/4130aecc644f716ed30ffc46818cb8afbc989c9c/gistfile1.txt

[Joshua Harlow (harlowja)]

Fix @ https://review.openstack.org/#/c/272326/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/272326
Committed: https://git.openstack.org/cgit/openstack/taskflow/commit/?id=84c7a7b2c7dcbade1bc802cac7c93ccd9b746cb3
Submitter: Jenkins
Branch: master

commit 84c7a7b2c7dcbade1bc802cac7c93ccd9b746cb3
Author: Joshua Harlow <email address hidden>
Date: Mon Jan 25 15:56:07 2016 -0800

    Fix process based executor task proxying-back events

    Let's dive into what the problem is here.

    First a description of what happens to a task that
    is to be executed in a external (but local) process
    via the process executor mechanism.

    When a task is about to be sent to execute in the
    external (but local) process its first cloned, this
    is mainly done so that its notification callbacks can
    be altered in a safe manner (ie not altering the
    original task object to do this) and that clone has
    its notifier emptied out.

    What replaces the clone's notifier callbacks though
    is a new object (that has a __call__ method so it
    looks like just another callback) that will send
    messages to the parent process (the one that has
    the engine in it) over a secure(ish) channel whenever
    the local task triggers its notifier notify() method.

    This allows for callbacks in the parent process to
    get triggered because once the messages recieved the
    original tasks notifier object has its notify() method
    called (therefore those callbacks do not really know
    the task they are getting messages from is executing out
    of process).

    The issue though is that if the ANY(*) event type is registered
    due to how it works in the notifier is that if the child/cloned
    notifier has the ANY event type registered and the cloned task
    calls notify() with a specific event this will cause the ANY
    callback (in the clone) to transmit a message *and* it will
    cause the *specific* event callback to also transmit a message
    back to the parent process.

    On the engine process side it will get 2 messages and trigger
    the callbacks 3 times (twice for the specific event callback
    because how the local notifier has the ANY callback registered
    and one more time when the local process also sends the same
    event based on its registration of the ANY event in the child
    process).

    This is not what is expected (the message rcved on the engine
    process should only trigger one callback to get triggered
    if the engine process task has no ANY callback registered or two
    engine process callbacks to get triggered if the engine process
    task has the ANY callback registered).

    Closes-Bug: #1537948

    Change-Id: I271bf1f23ad73df6c177cf00fd902c4881ba44ae

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/taskflow 2.14.0 release.