Etherpad setHTML接口调用成功但更新的HTML内容未在页面显示问题

这个问题属于实时协作服务内存状态与存储层数据不一致的典型表现，接口返回成功仅代表DB写入完成，页面渲染受内存缓存、实时推送、版本控制三层逻辑影响，可按以下步骤排查：

1. 校验内存缓存更新逻辑 #

• 完成过会话创建的pad会在实时服务的内存中生成对应的padState缓存对象，正常访问场景下服务端优先返回内存缓存的内容给前端，不会每次都读取DB。
• 排查点：检查/setHTML接口的业务逻辑，确认写入DB操作完成后，是否同步更新了内存中对应padID的缓存内容，是否标记了缓存失效的强制刷新标识。如果接口仅写DB不更新缓存，就会出现数据落地但页面拿不到最新内容的问题。

2. 校验全量更新推送逻辑 #

• 新建pad无活跃会话时，用户首次访问会主动拉取全量数据，所以更新可以正常展示；已有活跃会话的pad前端会通过长连接监听增量更新事件，默认不会主动全量拉取DB数据。
• 排查点：确认/setHTML执行全量内容更新后，是否向该padID绑定的所有活跃前端会话推送了全量内容更新通知。可以在调用接口后手动刷新pad页面试试，如果刷新后内容正常展示，即可确定是推送逻辑缺失导致的问题。

3. 校验内容版本号递增逻辑 #

• 协作类pad通常会为每次内容变更生成递增的revision版本号，前端会比对本地版本号与服务端版本号判断是否需要更新渲染。如果/setHTML写入DB后没有递增对应pad的版本号，前端会判定本地内容为最新版本，不会触发更新。
• 排查点：调用/setHTML前后分别查询该pad的最新版本号，确认版本号是否正常递增，若未递增需要在接口逻辑中补充版本号更新的代码。

临时应急方案 #

未定位根因前可先在/setHTML接口的执行末尾添加临时逻辑：强制销毁该padID对应的所有内存缓存和活跃会话，用户下次访问时会自动从DB拉取最新数据重建缓存与会话。

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