DocumentDB 4.0使用start_at_operation_time启动变更流报错排查

问题重现 #

执行代码：

stream = coll.watch(full_document="updateLookup",start_at_operation_time=x)

抛出错误：

pymongo.errors.OperationFailure: modifyChangeStreams has not been run for this collection/database/cluster, full error: {'ok': 0.0, 'operationTime': Timestamp(1704966523, 1), 'code': 136, 'errmsg': 'modifyChangeStreams has not been run for this collection/database/cluster'}

但不带start_at_operation_time参数的stream = coll.watch(full_document="updateLookup")可正常运行，说明Change Streams已启用。当前使用DocumentDB 4.0，官方文档表明start_at_operation_time功能受支持，集合自2019年有数据，尝试2019-2024年时间戳均报相同错误。

参考社区案例翻译 #

原MongoDB社区论坛未解决帖子内容翻译如下：

有用户反馈在使用Change Streams的startAtOperationTime参数时遇到问题：调用带有该参数的watch方法时，返回错误码136，提示modifyChangeStreams未运行，但不带该参数时能正常创建变更流。用户使用的是MongoDB 4.2版本，已经对目标集合启用了Change Streams，尝试过不同的时间戳值，包括最近的操作时间，都无法解决问题。其他用户回复中提到，可能是集群的oplog保留时间不足，或者时间戳对应的操作已经被清理，但用户确认oplog保留足够久，时间戳在有效范围内。还有用户建议检查是否在分片集群中操作，或者是否有权限问题，但均未找到有效解决方案。

可能的解决方向 #

• 检查DocumentDB的oplog保留策略：虽然集合自2019年有数据，但DocumentDB的oplog可能没有保留那么久的历史操作记录。start_at_operation_time指定的时间戳必须在oplog的保留范围内，否则会触发错误。可以通过查看DocumentDB的oplog保留配置，确认指定的时间戳是否在有效区间内。
• 确认时间戳格式正确性：确保传入的x是有效的bson.Timestamp类型，而不是普通的时间戳数值。比如需要用bson.Timestamp(1704966523, 1)这种格式，而非直接传入整数。
• 尝试从集群级别启用Change Streams：虽然集合级已启用，但部分情况下，使用start_at_operation_time可能需要集群级的Change Streams配置。可以尝试运行db.adminCommand({modifyChangeStreams: 1, enable: true})来确保集群级启用。
• 联系AWS支持：由于这是DocumentDB特有的环境，可能存在官方文档未覆盖的细节或环境问题，联系AWS技术支持排查具体集群的配置情况。

内容的提问来源于stack exchange，提问作者Shivam Anand