Skip to content

fix(ros): gate unusable local templates before the first API call - #198

Open
ruanzhengxin-zhuxing wants to merge 1 commit into
mainfrom
harness/1914185e
Open

fix(ros): gate unusable local templates before the first API call#198
ruanzhengxin-zhuxing wants to merge 1 commit into
mainfrom
harness/1914185e

Conversation

@ruanzhengxin-zhuxing

Copy link
Copy Markdown
Collaborator

Problem

ROS template tools reported an unusable local template as an invalid body_file — a parameter the caller never sent. Callers passing template_url therefore could not tell what to fix from the first failure, and retried the same template input across ros_validate_template, aliyun_api ValidateTemplate, and ros_preview_template before resorting to bash to inspect the file.

Two defects produced that message:

  • No pre-call readability gate. Permission checks only authorized the template path, so a missing or non-regular template still returned allow and only failed later, while the wire layer materialized the request body.
  • A swallowed error type. _read_body_file converts read failures into ApiContractError("invalid_body_file"), but the local-template branches caught only (OSError, UnicodeError). The error escaped to the generic handler and lost both its template-source context and its structured report.

Observed before the fix — the most common failure mode returned the least diagnostic information:

Local template state Permission stage Final error Structured report
missing allow body_file is invalid none
path is a directory allow body_file is invalid none
not UTF-8 allow ROS1202 report ros_validation

Change

Classify local templates (missing / not-regular / unreadable / too-large) before credentials, endpoints, and any request, and report every failure as a ROS1202 diagnostic carrying metadata.ros_validation plus a specific corrective action. The size ceiling is derived from the wire-layer limit so the gate and the transport cannot disagree.

Applied consistently to the runtime, legacy, and ros_stack read paths so the dedicated ROS tools and ros_deploy all fail the same way.

Genuine body_file inputs keep reporting invalid_body_file, and the success path is unchanged.

Verification

  • make test: 13282 passed, 4 skipped. Two failures are pre-existing and unrelated — verified failing identically on the untouched base commit d470b40 (a urllib error-class difference and an mtime-granularity ordering assumption).
  • make lint (ruff + ty): clean.
  • make translate run for the messages domain; the 7 new user-facing strings are translated across zh es fr de ja pt.
  • The 6 new regression tests were confirmed to fail when the fix is reverted, so they are not vacuous. They assert the failure names the template source and never body_file, and that no request is assembled (request_builder.inputs == []).

ROS template tools reported an unusable local template as an invalid
`body_file`, a parameter the caller never sent. Callers passing
`template_url` therefore had no way to tell what to fix from the first
failure, and retried the same template input across ros_validate_template,
aliyun_api ValidateTemplate, and ros_preview_template before resorting to
bash to inspect the file.

Two defects produced that message:

- No pre-call readability gate. Permission checks only authorized the path,
  so a missing or non-regular template still returned `allow` and failed
  later while the wire layer materialized the request body.
- `_read_body_file` converts read failures into
  `ApiContractError("invalid_body_file")`, but the local-template branches
  caught only `(OSError, UnicodeError)`. The error escaped to the generic
  handler and lost its template-source context and structured report.

Classify local templates (missing / not-regular / unreadable / too-large)
before credentials, endpoints, and any request, and report every failure as
a ROS1202 diagnostic carrying `metadata.ros_validation` plus a specific
corrective action. The size ceiling is derived from the wire-layer limit so
the gate and the transport cannot disagree. Applied consistently to the
runtime, legacy, and ros_stack read paths so the dedicated ROS tools and
ros_deploy all fail the same way.

Genuine `body_file` inputs keep reporting `invalid_body_file`, and the
success path is unchanged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant