andrewmusselman opened a new issue, #1263:
URL: https://github.com/apache/tooling-trusted-releases/issues/1263
## Summary
When a committer submits the "Record a manual staging distribution" form
(`/distribution/stage/record/<project>/<version>`) with a platform that has no
staging URL (Docker Hub, npm, npm scoped), `shared.distribution._template_url`
raises `RuntimeError`, which propagates unhandled to the generic 500 error
page. The error message is correct ("Platform Docker Hub does not provide a
staging API endpoint."), but it is delivered as a server error with a request
ID and exposed traceback rather than as a form-level validation error.
## Reproduce
1. Navigate to `/distribution/stage/record/<your-project>/<your-version>` as
a committer.
2. Select **Platform: Docker Hub** (or npm, or npm scoped).
3. Fill in any plausible owner namespace, package, and version. Submit.
Result:
> ## Error
> Platform Docker Hub does not provide a staging API endpoint.
> An error occurred while processing your request. This has been logged and
will be addressed.
> Status code: 500
> Request ID: `9cd5c82f-5696-4cf2-a973-14f715ab5fce`
>
> ### Technical details
> ```
> Traceback (most recent call last):
> ...
> ```
## Expected
Either of the following would be reasonable:
1. The platform dropdown on the staging form excludes platforms that have no
`template_staging_url`, so the user never reaches a submittable state that will
fail. The two go together — there's no point letting a user select Docker Hub
on a "stage" form if no staging endpoint exists.
2. The submission fails gracefully with a flash message or in-form error,
status code 4xx (probably 400), no traceback shown.
## Actual
The `RuntimeError` raised by `_template_url` bubbles up through
`get_api_url` → `record_from_data` → the POST handler → the generic 500 page.
The user sees a request ID and an "addressed by ops" message, suggesting an
internal bug — when in fact the input was just invalid for this code path.
## Root cause
`atr/shared/distribution.py` raises `RuntimeError` for any platform whose
`DistributionPlatformValue` doesn't declare a `template_staging_url`:
```python
if template_url is None:
raise RuntimeError(
f"Platform {dd.platform.value.name} does not provide a staging API
endpoint."
)
```
`RuntimeError` is not in the set of exceptions the POST handlers translate
into user-facing form errors (compare `storage.AccessError`, which carries a
`status` and is caught and rendered). It therefore matches the catch-all 500
handler.
This behaviour predates PR #<this PR number> for #751 (`Track the staging
revision of a recorded distribution`) — the previous whitelist branch raised
the same `RuntimeError` and produced the same 500. Only the error message text
changed in that PR. Discovered while smoke-testing it.
## Suggested directions (not prescriptive)
1. **Filter the platform select at render time** for staging forms, so the
user can only pick from platforms with a `template_staging_url`. Pairs
naturally with the enum being the single source of truth. Best UX, most code.
2. **Replace `RuntimeError` with a typed exception** (e.g.
`distribution.PlatformNotStageableError` or reuse
`storage.AccessError(status=400)`) and catch it in the POST handler the same
way other user-input errors are caught. Small and surgical.
3. **Add a form-level validator** that runs before `record_from_data` is
called, checks whether the chosen platform has a staging URL when
`staging=True`, and rejects the submission with a field-level error. Closest to
the existing form-validation pattern.
Option 1 prevents the error from ever happening, but option 2 is still worth
doing as a defence-in-depth measure for any future code path that calls
`_template_url` outside the form layer.
## Severity
Low. The platforms affected (Docker Hub, npm, npm scoped) don't currently
have working manual-record staging anyway. Users get a confusing experience but
no data corruption or security issue. Fix is small.
## Related
- PR for #751 — the message text comes from there, but the propagation
behaviour is unchanged.
- #938 (Hex/Erlang) — if Hex is added as a `DistributionPlatform` without a
staging URL (which is likely, since Hex has no staging registry), it will hit
the same code path with the same outcome until this is fixed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
