Continuing the discussion from Platform Update - Release Notes– 07/15/2015:
Can someone explain this one a bit more? Sounds intriguing. Is this for when a device does not respond right away? Do requests to that device queue up and resend?
2 Likes
Can you please elaborate on this for the community? Thanks!
1 Like
Good question. This is an implementation detail and is referring to an enhancement for how we process device event messages as they come into the platform from hubs and devices.
For context, as events from devices flow into the SmartThings platform, we store them in Cassandra. We then route these events through a queue to fire SmartApps. This queuing allows us to spread out the work across multiple server instances, since multiple SmartApps can fire in response to the same event.
Because storing our events in Cassandra is eventually-consistent, there are times where a SmartApp worker can pull the message off the queue before it’s available to be read from Cassandra. This isn’t common, but it can happen. In these cases, we re-queue the message to be looked up again.
This item in Naren’s post is pointing out some work that we did to update this logic. It doesn’t have any impact on the community, but was included here to be transparent about what we’re working on with each release. In retrospect, it’s an obscure enough implementation detail to have raised more questions than it answered.
1 Like
The next update mentioned MyQ connect app. Seriously. Where’s the MyQ connect app in ST?
This was referring to a fix for the MyQ Connect app authored by @copyninja, not one by ST.