进程外命令失败处理最佳实践咨询：密码变更场景的用户通知方案

咱们先明确核心需求：这个REST端点只负责接收密码变更请求，把命令转发给身份提供商，不处理身份相关逻辑，关键是要在操作出问题时通知到用户。下面分析两种常见方案，以及更优的实践思路：

方案1：发完命令等响应事件再返回客户端 #

• 适合场景：密码变更操作本身耗时短（几秒内能完成），用户可以接受短暂等待的情况。
• 好处：
  • 用户体验直接，客户端提交请求后能立刻拿到结果，不用额外操作。
  • 流程简单，用Brighter的请求-响应模式就行——端点发送命令后，等着身份提供商发回结果事件，成功就返回200，失败就返回对应的错误码和原因。
• 要注意的点：
  • 必须设合理的超时时间，别因为身份提供商卡壳导致REST请求一直挂着。
  • 要处理消息中间件的异常，比如消息发不出去的话，直接告诉用户“操作提交失败，请重试”。

方案2：异步提交+客户端轮询状态 #

• 适合场景：密码变更要走多步验证、同步多个系统，耗时较长；或者身份提供商没法及时给响应的情况。
• 好处：
  • 不会让REST请求长时间阻塞，能提升端点的处理能力和稳定性。
  • 适配复杂的异步流程，比如身份提供商分批处理任务的情况。
• 怎么实现：
  • REST端点收到请求后，生成一个唯一的操作ID，把命令扔进消息队列，然后立刻返回202 Accepted，同时把这个操作ID给客户端。
  • 单独做一个/password-change/status/{operationId}接口，让客户端定时轮询查状态。
  • 身份提供商完成操作后（不管成功失败），把结果更新到数据库里，轮询接口直接读这个状态返回给用户。

更高效的补充：异步推送通知 #

要是不想让用户主动轮询，还可以用Webhook或者推送通知：

• 用户提交请求时，前端提供一个临时的回调URL（或者用用户的设备推送令牌）。
• 身份提供商搞定操作后，直接调用这个回调URL，把结果推给客户端。
• 这种方式更省资源，尤其适合移动端或者对实时性要求高的场景。

选方案的原则 #

• 操作快、响应可靠的话，优先选等响应事件返回的方案，用户体验更好。
• 操作慢、异步性强的话，选异步提交+轮询/推送，保证系统不卡壳。
• 不管用哪种方案，都要确保消息不会丢：比如开Brighter的消息持久化、重试机制，别因为命令丢了导致用户那边状态乱了。

内容的提问来源于stack exchange，提问作者Lasse Vabe Rolstad