Bug 1548781 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Dustin, I believe it's the same problem with the binding: `queueEvents.taskFailed(`route.${this.context.cfg.app.statusTaskRoute}`)`
- they have a decision task.

To solve the immediate need, I would roll back Checks altogether (we are the only people using them anyways, and I am in a different project at the moment), use only Statuses everywhere and return to the old `schedulerId` bindings.
Dustin, I believe it's the same problem with the binding: `queueEvents.taskFailed(`route.${this.context.cfg.app.statusTaskRoute}`)`
because they have a decision task.

To solve the immediate need, I would roll back Checks altogether (we are the only people using them anyways, and I am in a different project at the moment), use only Statuses everywhere and return to the old `schedulerId` bindings.
Dustin, I believe it's the same problem with the binding: `queueEvents.taskFailed('route.${this.context.cfg.app.statusTaskRoute}')`
because they have a decision task.

To solve the immediate need, I would roll back Checks altogether (we are the only people using them anyways, and I am in a different project at the moment), use only Statuses everywhere and return to the old `schedulerId` bindings.
Dustin, I believe it's the same problem with the binding: `queueEvents.taskFailed('route.${this.context.cfg.app.statusTaskRoute}')`
because they have a decision task.

To solve the immediate need, I would roll back Checks altogether (we are the only people using them anyways, and I am in a different project at the moment so now work is being done), use only Statuses everywhere and return to the old `schedulerId` bindings.
Dustin, I believe it's the same problem with the binding: `queueEvents.taskFailed('route.${this.context.cfg.app.statusTaskRoute}')`
because they have a decision task.

To solve the immediate need, I would roll back Checks altogether (we are the only people using them anyways, and I am in a different project at the moment so no work is being done), use only Statuses everywhere and return to the old `schedulerId` bindings.

Back to Bug 1548781 Comment 2