Jens Reimann

> I am not sure if I understand your concern here. FMPOV it is as you said: either the delivery is processed first or the timer task is running first....

> And _if_ we found a case where the delivery processing handler was run in a non-vert.x thread, potentially causing such a race condition, we would have to fix that...

I agree that it would nice that would be synched automatically. Then again it would make much sense in the current case. The additions are a coap secret (where coap...

I think it would be a good idea to wait that until PR #809 is merged. Otherwise this will create conflicts.

I can confirm that the swagger configuration parameters never get applied. Digging a bit into the source I found that the "updated" method of the `SwaggerConfiguration` class does get called...

I just found a workaround, at least for the "swagger.info" part. It is possible to add a `@SwaggerDefinition` annotation to any service registered with the OSGi connector. This gets picked...

This is what I can see in the log: ~~~ [2020-09-07T13:00:29Z INFO hawkbit_operator::controller] Reconcile: hawkbit-operator/default [2020-09-07T13:00:29Z INFO hawkbit_operator::controller] Reconcile: hawkbit-operator/default [2020-09-07T13:00:29Z INFO hawkbit_operator::controller] Reconcile: hawkbit-operator/default [2020-09-07T13:00:29Z INFO hawkbit_operator::controller] Reconcile: hawkbit-operator/default...

> In that case, the old queue entry should be reused. Is `hawkbit_operator` public? Yes: https://github.com/ctron/hawkbit-operator

Maybe it would make sense do add some rate limiting feature, as in the Go version of the controller runtime: * https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/ratelimiter/ratelimiter.go * https://github.com/kubernetes/client-go/blob/master/util/workqueue/rate_limiting_queue.go

I would also be interested in a similar functionality. My use case is to create up a changelog up until the latest non-milestone release. To my understanding, currently I can...