查询符合条件却未必已经入组：AWS动态设备组的三层状态

AWS IoT Core的Dynamic thing groups文档，从注册表中的查询条件定义动态设备组。组内成员不是逐个明示列入，而由查询决定；相关功能又以fleet indexing为前提。[1] 因此，一份动态组资料至少包含条件与成员结果两种信息：前者说明哪些设备符合范围，后者才说明设备实际处在哪个组中。连接状态、软件版本和型号，是原文列举的条件对象，并非本文创建的查询。

成员结果还需要经过回填。文档说，动态组创建时状态为BUILDING，回填完成后转为ACTIVE；调整搜索查询后的成员更新，则经历REBUILDING，再回到ACTIVE。两个处理中状态各有来历：一处伴随新组形成，另一处伴随已有组条件改变。仅看见组的名称和查询文字，尚不能知道当前结果是否完成了这一阶段。

Describe部分将queryString与status列作动态组特有的返回信息。查询字符串表达成员条件，状态则表达集合处理到了哪里，两者没有互相替代。该节特别注明，BUILDING和REBUILDING期间可能尚未包含全部匹配设备。ACTIVE的说明需要放回回填语境阅读；后面的限制段又另行讨论单个设备能否加入，不能把一个状态名称扩展成不受任何成员条件限制的保证。

限制段先提出设备能够属于的组数量上限。设备符合新动态组条件时，若尚未达到上限，文档描述它被加入该组；若已经达到上限，就继续区分它是否已属于某个动态组。没有已有动态组可供替换的情形下，新组无法加入，并产生错误记录和入组失败指标。这里发生的差别不在查询是否匹配，而在同一设备已经占有的成员关系。

存在已有动态组时，文档再比较组的年龄。如果待加入组比设备所属的某个动态组更老，设备可以从其最新的动态组移出，再加入较老的组；若没有这样的较新组，则仍无法加入。来源随后以“较老动态组优先于较新动态组”概括这一关系。查询相符提供资格，已有成员关系与组的先后又影响结果，所以一份匹配清单不能直接充当实际入组清单。

这些逐设备结果，也解释了另一项容易混淆的记录：创建或更新调用成功，仍可能有设备符合条件却未加入。AWS明确说，这种情况会记录错误并产生AddThingToDynamicThingGroupsFailed指标，一项指标可以代表多个日志条目。调用的成功是在描述一次组操作，错误日志则进入具体成员结果；两种记录粒度不同，不能用其中一个名称抹掉另一个。

正常条件变化引起的增减，又被文档单独说明。组内设备不再符合搜索条件时会移出；设备资料变化后符合条件，则按前述关系加入。这类正常增减不产生上述错误日志，与为了加入另一组而从既有动态组移出的情况不同。判断资料中的“移出”所指何事，因而还需要看它对应条件变化，还是达到上限后的组间替换。

最后，成员关系被定义为最终一致。原文说，注册表只评估最终状态，快速更新的中间状态可能被跳过。它没有把最终成员结果定义成每一次短暂状态都曾完整进入集合的历史。本文仅阅读该页条件、回填与限制的连续文字；首次发布日期未知，未执行命令、设置权限、控制设备或据此给出日志排障及消息可靠性保证。