Order-of-operations issue in service.py where setup_calls can send a message to queue before it necessarily exists. Possibly solution to #28 will fix this too.
Reproduce by:
spin up a new RabbitMQ broker with nothing declared (I used gus)
start a new service with a setup_call that will result in a value being logged
observe an error:
2018-06-04T17:19:51[DEBUG ] dripline.core.service(556) -> to sensor_value.endpoint_name sending {
<the usual stuff>
}
2018-06-04T17:19:51[ERROR ] dripline.core.scheduler(79) -> got a: (404, "NOT_FOUND - no exchange 'alerts' in vhost '/'")
Workaround: Remove the setup_calls, run any service to declare the two exchanges, then run as before and it works.
How have we not seen this before? Possibly because enough services have no setup calls and the exchanges get declared promptly? Possibly it's happened but before slack is up so we don't see the errors (slack has no setup_calls, so it will always work)?
Order-of-operations issue in service.py where setup_calls can send a message to queue before it necessarily exists. Possibly solution to #28 will fix this too.
Reproduce by:
Workaround: Remove the setup_calls, run any service to declare the two exchanges, then run as before and it works.
How have we not seen this before? Possibly because enough services have no setup calls and the exchanges get declared promptly? Possibly it's happened but before slack is up so we don't see the errors (slack has no setup_calls, so it will always work)?