Currently, when tc-gh is switched to the Checks API mode, it doesn't report status for the tasks that are started by a decision task. The reason being, the handler are bound to the RabbitMQ queues with a special task-specific route (in `routes` array in the task definition) - decision task would have that special route, but the tasks that it triggers will not, unless the user adds them to the task definitions by hand. The idea of using primary key for bindings has been ruled out. This bug is a major blocker to deploying Checks API implementation.
Bug 1533235 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Currently, when tc-gh is switched to the Checks API mode, it doesn't report status for the tasks that are started by a decision task. The reason being, the handler are bound to the RabbitMQ queues with a special task-specific route (in `routes` array in the task definition) - decision task would have that special route, but the tasks that it triggers will not, unless the user adds them to the task definitions by hand. The idea of using primary key for bindings has been ruled out. Alternative solution is being worked on in Bug 1252144 This bug is a major blocker to deploying Checks API implementation.
Currently, when tc-gh is switched to the Checks API mode, it doesn't report status for the tasks that are started by a decision task. The reason being, the handler are bound to the RabbitMQ queues with a special task-specific route (in `routes` array in the task definition) - decision task would have that special route, but the tasks that it triggers will not, unless the user adds them to the task definitions by hand. The idea of using primary key for bindings has been ruled out. Alternative solution is being worked on in Bug 1252144 This bug is a blocker to deploying Checks API implementation.
Currently, when tc-gh is switched to the Checks API mode, it doesn't report status for the tasks that are started by a decision task. The reason being, the handler are bound to the RabbitMQ queues with a special task-specific route (in `routes` array in the task definition) - decision task would have that special route, but the tasks that it triggers will not, unless the user adds them to the task definitions by hand. The idea of using primary key for bindings has been ruled out. Alternative solution is being worked on in Bug 1252144