フィーチャーレイヤーからのFetch更新、変更、または削除を使用するすべてのフローでのBad Request Error 400。

KylaCupp_SBY

Power Automateを使用して複数のフローを実行していますが、フィーチャーからのFetch更新、変更、または削除でBad Request Error 400が発生し、フローが失敗することが定期的にあります。リトライ回数を増やしてみましたが、サービスに到達できないためリトライされないと思います。手動で再送信すると、フローは正常に実行されます。 <\/P>

この問題は2026.2アップデート後に発生し始めたようですが、相関関係は因果関係ではないことは承知しています😅<\/span>。詳細に調査して補助フローを作成することもできますが、これはバグの可能性があるか、元のフロー内で修正できるべき問題だと感じています。このフローへのより良いアプローチ方法があるかもしれませんが、本質的にはフィールドの変更をチェックするものです。<\/P>何かご提案いただけると幸いです！ <\/P>ありがとうございます！<\/P><\/span><\/span><\/P>

Akshay Harshe

 

It looks like this may be an intermittent issue. When you mentioned that you "tried increasing the number of retries," are you referring to the Retry Policy setting under the action's settings? If not, I'd recommend trying that first. You could also add a delay of around 30 seconds before the Fetch action to see if that improves reliability.

 

The "Sync replica internal error" is being returned by ArcGIS Online and it is unrelated to either the ArcGIS Connector or the 2026.2 update. This error indicates that something is failing internally within the service. Based on the details provided, it may be related to editor tracking, as the Extract Changes endpoint can sometimes return this error under those conditions.

In some cases, this is a temporary issue. Resubmitting the request generates a new call to the Extract Changes endpoint, which may succeed. As a troubleshooting step, you can copy the changesUrl returned by the webhook action, append a valid ArcGIS token, and invoke the REST endpoint directly. If the same error occurs there, it would further confirm that the issue originates from ArcGIS Online rather than the connector.

One resolution that has helped in similar cases is to disable editor tracking and then re-enable it. Please note that this approach can result in the loss of editing history, so it should be considered carefully.

At this point, I would recommend opening a support case with the ArcGIS Online team, specifically regarding the Feature Service Extract Changes endpoint. They should be able to investigate the underlying service-side failure.