Triggered listeners scheduled during startup or later never get triggered

[ddgenome]

If you call sdm.addTriggeredListener() within a startupListener or later, it never gets triggered. This seems to be due to the fact that the only time triggeredListeners get scheduled is during startup as part of the last startupListener, but the startupListeners execute in parallel. Thus the startupListener that calls scheduleTriggeredListeners can execute before another startupListener that adds a triggeredListener executes, leaving that triggeredListener never processed.

Is there a reason that call addTriggeredListener() just doesn't deal with the the scheduling of the triggeredListener itself? In other words, is there a reason the scheduling is deferred to the last startupListener? If not, then I'd recommend we just handled the scheduling within addTriggeredListener so people can call that at any point during the execution of the SDM. If there is a reason, then I'd recommend we not execute scheduleTriggeredListeners in parallel with the startupListeners but after the startupListeners have completed.

[ddgenome]

Relevant code: https://github.com/atomist/sdm/blob/4be980693fee5ca2469dc9c96a83fdbd180e9190/lib/api-helper/machine/AbstractSoftwareDeliveryMachine.ts#L266-L306

This line in particular is the problem because it runs all startupListeners in parallel and does not await the result even though it seems like it does: https://github.com/atomist/sdm/blob/4be980693fee5ca2469dc9c96a83fdbd180e9190/lib/api-helper/machine/AbstractSoftwareDeliveryMachine.ts#L279

[ddgenome]

Or perhaps we deprecate triggeredListeners in 2.0 since they are not managed by the API/backend? With job support, they have become a wrapper around what Node.js can already do.

[atomist[bot]]

Thanks for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.