Hello,

I'm seeing issues with the settings>info page in mercurial repositories. I'm unable to change either the description, or visibility. Pressing Save refreshes the page and reverts the form.

The only recent commit (b799aaf89166) seems to touch on some settings/visibility code, but not in a way that would introduce the bug above. At least to my eye.

Mentioned the issue in chat.sr.ht, but didn't see much engagement / confirmation.

-- 
Regards,
   Marcus

Indeed... I can't repro the problem with my test server however.

As far as I can tell, the POST request goes to the server from the web
form, and then the GQL query to update the repository info gets
received by the GQL service. I don't yet know why that GQL query
doesn't do anything. Does anybody have tips for debugging that?

When I used that Save button in February, it worked correctly.
Now it doesn't.

I found an anomaly that is probably related...

I can change a repository's description, by navigating to
https://hg.sr.ht/graphql and submitting this:

  mutation {updateRepository (id: 12345,
                              input: {description: "Lorem ipsum"})
             {name, description, updated}}

(except, of course, with a real repository's ID instead of "12345").

If I try to change its visibility, by submitting this:

  mutation {updateRepository (id: 12345,
                              input: {visibility: UNLISTED})
             {name, visibility, updated}}

I get the error message "Expected visibility to be a string" from
https://hg.sr.ht/graphql , but if I submit that same command into
https://git.sr.ht/graphql , I do _not_ get an error message, and
the repository's visibility changes to "unlisted".

>> Does anybody have tips for debugging that?

If the problem only happens on the live server, and you can't
attach a debugger to it, but you can deploy new code onto it,
I'd suggest something like this:

Find one or more places in the source code that can create an
"Expected <thing> to be <type>" error message.  Change the code
to insert the text of a stack backtrace into the text of that
error message.  Build, deploy, submit a mutation command to
https://hg.sr.ht/graphql .  You might be able to deduce the
problem just by looking at the backtrace; if not...  Create a
per-HTTP-request variable that holds appendable text.  At one
or more of the places mentioned in the backtrace, add code that
"prints" useful information (e.g. variable values) into that
appendable variable.  Go back to the place(s) where the backtrace
text is inserted into the error message text, and change the code
to also insert the text of the appendable variable into the error
message text.  Build, deploy, submit, etc.

Hey there, sorry about the delays on this (I have been traveling a lot
these past two months).

Anyway, Robert's earlier email about the GraphQL error pointed to the
issue: it was parsing visibility as a string instead of an enum (or
whatever Golang calls these). I just compared that portion of code to
gitsrht to [fix it][1]. Thanks for reporting the bug and helping
troubleshoot it, everyone!

Of course, ping me if there are any undesirable side-effects.

[1]: https://hg.sr.ht/~sircmpwn/hg.sr.ht/rev/142169607dba61bffcf5f9d7ec58c13aba1beb9f

Ludovic,

Everything seems to be good on my end. Did a couple tests flipping
the settings around in different repositories. Worked successfully.

Thank you all for your time and dedication on this issue.