Short version: skill-flow-bellevue-weather and skill-flow-multi-city-weather failed in run adhoc-2026-09-23_16-15-07 because Open-Meteo refused the request with HTTP 429 "Daily API request limit exceeded". The flows never got past their first HTTP node. The checker scored this as a flow defect (0.375) instead of an environment failure.
Evidence
- v1 bellevue, checker debug (task.log:197):
Unified HttpRequest failed with status code '429', message: {"code":429,...,"body":{"error":true,"reason":"Daily API request limit exceeded. Please try again tomorrow."}} (17:50:27 UTC). The agent's own debug at 17:49:31 got the same 429.
- v1 multi-city (task.log:198, 17:49:04 UTC) and v2 multi-city (task.log:298, 17:48:34 UTC): the same 429 body.
- In the same window, v2 bellevue passed (graded 17:48:38-17:49:07) and group-to-subflow passed in both arms at 17:58-17:59. So the block was intermittent. The cause of that is not known. One possible reason is several IS egress IPs with separate quotas; this is not verified.
- In the whole run archive (
runs/*/.../task.log), this error text appears only in these 3 logs, so this cause is new. Earlier failures of these rows had other causes: empty outputs, a 400 on wind_speed_unit, a 102018 null body, and a loop without a parentId.
Why this can happen
- The prompts require a direct call to the free public API (
bellevue_weather.yaml:26, multi_city_weather.yaml:23: "call the open-meteo API directly").
- The call runs from the Integration Service HTTP runtime. Open-Meteo therefore sees UiPath's shared egress IPs, so the free daily quota is shared with every IS tenant using those IPs. The eval does not own that quota and cannot see it.
_shared/flow_check.py treats every Faulted debug as a verdict on the flow. It has only two exceptions: the retry markers at :138-142 (5xx, RetryLater, poll timeout) and the INFRA path at :126 and :569-574, which covers unreadable outputs only. An upstream quota answer falls through both and is scored as a content failure. The file is identical on current main.
Proposed fix
- In
run_debug (or assert_outputs_contain), recognise a Faulted run whose incident errorDetails carries an upstream status code '429' or a rate-limit or quota body. Fail it with the existing INFRA wording ("environment failure, not a flow defect"). Do not retry, because this is a daily quota.
- coder_eval has no way for a
run_command criterion to land a row as ERROR; today only pre_run failures and escalating exceptions do. Adding a reserved exit code for this would take INFRA rows out of pass-rate comparisons. Needs a coder_eval issue if accepted.
- A
pre_run probe from the container does not fix this. It would test the container's IP, not the IS egress.
Rows affected in this run: v1 bellevue-weather, v1 and v2 multi-city-weather. Other rows that call Open-Meteo (add-node, add-output, move-node, remove-node, update-node, group-to-subflow, slack-weather-pipeline) are exposed in the same way.
Found during the Flow v1-vs-v2 gap campaign (run adhoc-2026-09-23_16-15-07). Not fixed in that campaign; filed so the defect is tracked.
Short version:
skill-flow-bellevue-weatherandskill-flow-multi-city-weatherfailed in run adhoc-2026-09-23_16-15-07 because Open-Meteo refused the request with HTTP 429 "Daily API request limit exceeded". The flows never got past their first HTTP node. The checker scored this as a flow defect (0.375) instead of an environment failure.Evidence
Unified HttpRequest failed with status code '429', message: {"code":429,...,"body":{"error":true,"reason":"Daily API request limit exceeded. Please try again tomorrow."}}(17:50:27 UTC). The agent's own debug at 17:49:31 got the same 429.runs/*/.../task.log), this error text appears only in these 3 logs, so this cause is new. Earlier failures of these rows had other causes: empty outputs, a 400 onwind_speed_unit, a 102018 null body, and a loop without aparentId.Why this can happen
bellevue_weather.yaml:26,multi_city_weather.yaml:23: "call the open-meteo API directly")._shared/flow_check.pytreats every Faulted debug as a verdict on the flow. It has only two exceptions: the retry markers at :138-142 (5xx, RetryLater, poll timeout) and the INFRA path at :126 and :569-574, which covers unreadable outputs only. An upstream quota answer falls through both and is scored as a content failure. The file is identical on current main.Proposed fix
run_debug(orassert_outputs_contain), recognise a Faulted run whose incidenterrorDetailscarries an upstreamstatus code '429'or a rate-limit or quota body. Fail it with the existing INFRA wording ("environment failure, not a flow defect"). Do not retry, because this is a daily quota.run_commandcriterion to land a row as ERROR; today onlypre_runfailures and escalating exceptions do. Adding a reserved exit code for this would take INFRA rows out of pass-rate comparisons. Needs a coder_eval issue if accepted.pre_runprobe from the container does not fix this. It would test the container's IP, not the IS egress.Rows affected in this run: v1 bellevue-weather, v1 and v2 multi-city-weather. Other rows that call Open-Meteo (add-node, add-output, move-node, remove-node, update-node, group-to-subflow, slack-weather-pipeline) are exposed in the same way.
Found during the Flow v1-vs-v2 gap campaign (run
adhoc-2026-09-23_16-15-07). Not fixed in that campaign; filed so the defect is tracked.