Using pijul pull --from-channel <channel> with a bad channel currently returns Downloading changes... Nothing to pull for local remotes, and shows the raw 404 for http remotes.

I think it’s preferable to let the user know they’re looking for a channel that doesn’t exist, and to let them know if they have a bad remote altogether in the case of an http request. In the patch below, if the channel can’t be found during an http request, a head request is made to the remote root to see whether the remote itself exists.

Thanks! This is a good point, I’m changing the code on the Nest to return the exact error message, so we don’t have to send an extra head request to test. I’ll ping you when I’m done.

Also, would you mind adding the following lines to your .pijul/config:

[hooks]
record = [ "cargo fmt" ]

Alright, done. The Nest now returns a JSON value as the body when it fails with 404. If you parse that with serde_json::from_slice, you can get a libpijul::RemoteError. When the error is a known type, you can show a better error message.

If you want, you can amend your patch to use that new feature, and push it to this discussion.

you can get a libpijul::RemoteError

I’m not able to find that or anything matching the ChannelNotFound error I’m getting back from the head request. Also I’m having trouble cloning stuff; Error: Changestore error: ZSTD("Unknown frame descriptor"). The warn and err log levels aren’t showing anything.

This is strange. When I do curl "https://nest.pijul.com/pijul/pijul/.pijul?changelist=0&channel=bl", I get {"ChannelNotFound":{"channel":"bl","url":"pijul/pijul"}}, which is parseable with serde_json. Are you getting a different result?

Wait, maybe I wasn’t clear (I don’t know what you know): this is in the response body, and needs to be parsed.

Yeah, that’s the response I got, but my reading was that there was some libpijul::RemoteError item that you wanted the json to be parsed as. I can add an enum variant to libpijul::Error but that would require adding the Deserialize decoration to the whole enum.

Alternatively you can just return the pretty-printed serde value which already gives pretty good feedback:

Error: {
  "ChannelNotFound": {
    "channel": "fake_channel",
    "url": "pijul/pijul"
  }
}

Alright, I see: this is in the version of libpijul on the Nest, I introduced it today in #5GYRDN47UOT5BSCUID7VLDPI47KILTKGIHKG3AXMDPCTSHKKDB5AC

After flushing the browser cache, the last change I see is 3H6Q5L; 5GYRDN gives me an internal server error. I think the nest is having some regional issues; if I switch to a Finnish VPN server, I can see GUL4M5 and 5GYRDN (and your link works).

Ok, that’s alerady some stuff to investigate, thanks.

I believe it’s actually a caching issue, I see 5GYRDN on all three servers now. Strange…

If you mean browser cache, curl is still giving me a 500 in the US/Mexico, 200 everywhere else (Poland, Japan, Finland). Also I’m on Zulip a lot if you don’t want me blowing up your inbox.

Much delayed, but here it is now that the CDN/ssh stuff is clearing up. Also, the error returned from the nest for a non-existent repo results in a JSON deserialization error, it looks like it’s giving back the full 404 page instead of a RemoteError::RepositoryNotFound.

Thanks! I think a more direct way of writing it would be:

return Err(serde_json::from_slice::<libpijul::RemoteError>(&*res.bytes().await?)?.into())

What do you think?

Sure, I hadn’t really looked at the details of bail! before now.

Almost there: I think the problem you noticed with 404 can’t be fixed in a generic way from the Nest, because we also want to inform the user when they entered a wrong URL that doesn’t look like a Nest URL.

What would you think of adding a special case for 404s (such as a bail! of the right message)?

Ignore YQLD, I think UM7Z makes more sense.

Sorry to be pedantic :(

You don’t have to test for the Nest, any 404 on any server would indicate a “repository not found” error. Also, some non-Nest servers could send more “raw” errors, we have to take care of those too. Maybe you could (1) try to deserialize, and (2) test for a 404 because that’s a very common HTTP code, and then (3) send a raw bail!("HTTP Error {}", …).

I think that’s what UM7Z is doing. If the error deserializes, return that, if it’s a nest 404 handle that, then handle everything else with a generic bail. I’m not sure how to fulfill “we also want to inform the user when they entered a wrong URL that doesn’t look like a Nest URL” without checking the domain.

Oh, sorry if I expressed myself badly. I generally want to avoid tying Pijul to the Nest, what I meant was, something that isn’t even recognised by the server (not necessarily the Nest).

Now we’re talking! Applied, thanks, and sorry for being so pedantic.