chadtmiller.com/knotless

Switch repository

Loading…

What changes

The appview's gateway, which a runner that may not push lands a merge queue through when the repository names no gateway, and which knotless share --write and knotless delegate (and MCP delegate) with none named delegate to, is now the DID the appview's own DID document names, read from KNOTLESS_APPVIEW, as invites, secrets and organizations already find it. It was made from that address instead.

Why

On knotless.dev the runner that lands chadtmiller.com/knotless's queue moved from the owner's account to ci.knotless.dev, which is no collaborator, so it lands through the gateway. Beside serve on the prod host its appview is http://serve:2590, so it made did:web:serve%3A2590, resolved that over https, and failed every landing with received corrupt message of type InvalidContentType: batches passed their checks and never landed. Serve's document at that address names did:web:knotless.dev, the gateway the owner delegated to. Setting the repository record's gateway worked around it there; this fixes it for any runner beside its appview.

How it was checked

On the prod host, http://serve:2590/.well-known/did.json answers did:web:knotless.dev with its #knotless_gateway at https://knotless.dev. The lines changed run in the existing tests of sharing for writing, MCP delegate, and a runner landing through the gateway. The rest is left to CI.

Shortcomings

No test has an appview whose address differs from its public URL, which is the case this fixes. Delegating with no gateway named now reads the appview's DID document first: one more request, and an appview that cannot be reached fails it with that error rather than delegating to a DID that would not work.

gateway::appview now reads the appview's DID from its DID document (moderation::appview_did) instead of building a did:web from the KNOTLESS_APPVIEW address. That is the same lookup invites, secrets, org and notifications already use. I found no other caller of the old synchronous function: gateway.rs:155, manage.rs:344 and MCP delegate are all updated to .await. The new failure path (an unreachable appview now fails the delegate or landing) is stated in the PR's shortcomings. The changeset and the merge-queue design doc are updated. I didn't run the tests or check CI. As the PR says, nothing tests an appview whose address differs from its public URL, so that case is untested.