WebSocket新连接触发DynamoDB事件时connectionId重复问题排查

现象描述 #

在CloudWatch中发现，由DynamoDB新条目触发的事件，仅能偶尔成功传递新WebSocket连接的connectionId——每次新连接时，Broadcast Lambda函数打印的connectionId始终相同，仿佛存在延迟事件缓存。

操作流程 #

• 连接：通过本地前端连接WebSocket地址 wss://xxxxxx.execute-api.us-east-1.amazonaws.com/production，每次连接时Connect Lambda函数都会成功将不同的connectionId存储到DynamoDB表中。
• 触发：DynamoDB创建新条目时，触发器会向Broadcast Lambda函数发送事件。当前该函数仅打印事件中的connectionId到CloudWatch，但每次新连接打印的connectionId完全重复。
• 断开：前端结束WebSocket连接时，Disconnect Lambda函数会成功从DynamoDB表中删除对应的connectionId，但并未解决connectionId重复的问题。

核心疑问 #

1. 为何不同WebSocket连接会重复打印相同的connectionId？DynamoDB表工作正常，触发时理应传递正确的条目值。
2. CloudWatch中部分日志流为何会聚合，而另一些则单独存在？

相关代码（Broadcast Lambda） #

import json
import boto3

client = boto3.client('apigatewaymanagementapi', endpoint_url="https://xxxxxx.execute-api.us-east-1.amazonaws.com/production")

def lambda_handler(event, context):
    
    # get connectionId from DynamoDB
    print(event['Records'][0]['dynamodb']['Keys']['connectionid']['S'])

日志说明 #

• 日志1：多次新连接操作后，Broadcast函数打印的connectionId完全一致
• 日志2：不同连接对应的日志流中，均出现重复的connectionId输出

问题排查与解决建议 #

针对connectionId重复问题 #

1. 处理DynamoDB触发器的批量事件
   当前代码仅读取事件批次中的第一条记录（event['Records'][0]），而DynamoDB触发器默认会将多条操作事件打包成批次发送给Lambda。如果之前的未处理批次中包含旧的connectionId，新事件追加后仍打印第一条就会出现重复。
   修改代码遍历所有记录并仅处理插入事件：

   def lambda_handler(event, context):
       for record in event['Records']:
           if record['eventName'] == 'INSERT':
               print(record['dynamodb']['Keys']['connectionid']['S'])
   

2. 验证触发器的触发事件类型
   确认DynamoDB触发器仅监听INSERT事件，避免Disconnect时的REMOVE事件混入批次。如果触发器包含REMOVE，其事件中的connectionId是已删除的旧值，会导致打印重复。
3. 确认事件内容的准确性
   在函数开头打印完整的event对象，检查传入的事件是否确实包含新的connectionId：

   print(json.dumps(event, indent=2))
   

   如果事件本身没有新的connectionId，则需要检查Connect函数是否真的写入了新值，或DynamoDB表的connectionid主键是否唯一，避免重复写入。

针对CloudWatch日志流聚合问题 #

CloudWatch日志流的聚合是Lambda执行环境复用导致的正常现象：

• 当Lambda复用同一执行环境时，后续调用的日志会追加到同一条日志流。
• 冷启动、执行环境销毁重建，或高并发下多个执行环境同时运行时，会生成新的独立日志流。
• 可通过CloudWatch的日志过滤功能，按函数名或关键词统一查看所有日志，无需纠结流的聚合情况。

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