Carsten Lohmann

It seems the scenario here is similar to the one described in #3225. The Hono Command Router component is making requests to the Kubernetes API to check which Hono protocol...

The `WatcherExceptions` above point at some temporary instabilities concerning the K8s API server, I guess. While the `watcher` instance is stopped during that time, there shouldn't be any issues with...

The upcoming 2.0.2 and 2.1.0 releases will contain improvements regarding the handling of delayed K8s API server responses. I'm not sure whether in the scenario described in this issue there...

@mbaeuerle It's not a regression since the "Connection events" of #1714 (sent when a device (dis)connects) are different from the (dis)connectedTtd events mentioned here (sent when a device (un)subscribes for...

Actually, the default `ttl` for a device and the tenant `maxTtl` are already getting applied here (if "defaults" are enabled for the adapter). ~~What is missing is taking the `ttd`...

@Christian-Schmid @mbaeuerle Apart from the tenant `max-ttl` already getting set as time-to-live here, do you think it makes sense to have a separate `connection-event-ttl` device/tenant-level default property? This property could...

@sophokles73 FMPOV, introducing a new major API version just for these 2 property changes doesn't seem worth the effort. So I would also say to rather postpone this change to...

Initial idea: **Device side: Sending the request message** - to the MQTT adapter: - device chooses a correlation id - device subscribes to a topic `req_resp/${tenant-id}/${device-id}/resp/${correlation-id}/#` - device publishes request...

> HTTP adapter: [..] clients receive response (if any) in response body. FMPOV there is no need for a client to supply a correlation ID, this can be done by...

>> Right, the correlation ID can be set by the adapter (if the client hasn't explicitly provided one). > If we don't need the client to specify it, then IMHO...