考虑两个微服务“ A”和“ B”。说“ A”对“ B”进行POST调用，而“ B”执行基于某些ID检查重复请求的操作。如果操作成功，“ B”将返回200 OK响应。如果“ B”发现请求是重复请求，则返回409。
现在考虑一种情况，其中“ A”对“ B”进行POST调用。 “ B”成功处理，但是在它响应之前，连接超时，“ A”收到504超时错误代码。当服务“ A”重试该请求时，这次“ B”将其识别为重复请求并返回409响应，因为它已成功处理了“ A”提出的第一个请求。在这种情况下，服务“ A”应将其视为不可恢复的错误，还是应将其视为成功（假设其第一个请求已成功处理）？
...“ B”将此识别为重复请求并返回409回应...在这种情况下，服务“ A”应将其视为不可重试的错误，还是应该将其视为成功...
呼叫者能否就409状态是由先前呼叫的“成功”还是其他类型的“冲突”得出肯定的结论？我不知道，但是我可能不希望我的处理依赖于此。
是否有任何4xx响应状态是否应被视为“可重试”是一个问题。我认为，处理应假定该呼叫永久失败。
我从您的Q中得知，即使发生超时，B也会将下一个呼叫识别为重复的。首先，不要依赖/依靠它来获得成功。我宁愿查找该状态在哪里维护？它存储了多长时间，如果发生超时，则可以释放该状态，还是必须从A到B触发检查以知道该事务是否实际成功？例如，A发布客户信息，B超时。现在，在重试之前，请调用getCustomerInfo（cusomerName，customerId，x，y，z，...）以确认即使发生超时，Post还是在后台成功了。
[此外，您可能想深入了解B处的保留ID重复状态，以及您是否可以与B团队合作以尽早释放此许可证以进一步进行？
我也看到了在微服务A和B团队之间进行编排的机会，在这种情况下，排队服务可能会非常有益（仅在这种情况经常发生的情况下）。