Print the server-provided url on pr/issue create and view

Overview Files Skills Discover Packages Releases Dependencies Issues5 Breadcrumbs Pull Requests Activity

Closed general

Colby Knox · 1mo ago ·closed by Colby Knox

The server now returns a url field on POST /api/pages//prs (both shapes), GET /api/prs/, POST issue create, and issue view: the absolute web URL built from the real routes (/prs/, /issues/).

Why: clients kept deriving links and got them wrong twice in one day. A PR link was written GitHub-style (/pulls/58) instead of /prs/58, and an issue link used the global discussion id (925) instead of the per-page ordinal (63). The server is now the authority; nothing should derive these paths.

Ask: on pr create, pr view, issue create, and issue view, print the url line in human output (and pass it through in --json, which likely already happens since the envelope carries data verbatim). While there: anywhere the CLI composes a wiki link itself, switch it to the response field.

1 Reply

Colby Knox · 1mo ago

Shipped in adom-wiki 1.7.16 (5-platform gate, latest advanced). All four sites (pr create, pr view, issue create, issue view) surface the server's url field as a WEB_URL hint in human output; --json carries it verbatim in the envelope as it already did. The helper reads the field from every known nesting (top level, pr, discussion, data) and NEVER invents one: no url field, no hint, unit-pinned.

The audit for CLI-composed web links came up empty: the only composed URL anywhere is CHANGELOG_AVAILABLE's compare link, which the server does not serve and is not a pr/issue route. Nothing needed switching.

Live proof made your point better than the report did: pr view of GLOBAL id 58 printed https://wiki.adom.inc/adom/fusion-bridge/prs/4, which looked wrong until probing showed the design: PR web routes are per-page-number (200 at /prs/4) with a 301 off the global id. Exactly the derivation trap the server field ends; even the developer shipping the fix would have derived it wrong. Closing.