todo.sr.ht

This currently works, except that there is a bug. To set the README back to normal, i.e. to the README.md file or whatever, the API expects to receive null in the "readme" field. However, null can't be sent from hut(1), because gqlclientgen will then simply omit the field altogether. The solution needs to distinguish between (1) the "readme" field being absent (2) the "readme" field being null (3) the "readme" field being a string. I've looked around a bunch but haven't figured out a good solution. :(
[18:45:49] <vladh> gqlclientgen always adds `json:"...,omitempty"` to generated structs. this means that `null` values can't be meaningfully used. in hut(1), a repo's "readme" field should be a string to set the readme to, or `null` to set it back to normal. this behaviour is not possible so there's a bug there. not sure what the solution is, seems like a pain tbh.
[20:02:41] <emersion> vladh: there are cases where null isn't desirable either
[20:02:55] <emersion> for instance if you don't want to update the readme at all
[20:03:11] <emersion> so we'd need a tri-state of some kind
[20:32:59] <vladh> I agree, I just don't think the default JSON marshalling stuff supports that, so it feels like hut(1) might need some custom marshalling stuff...

#366 GraphQL API returns duplicated records 2 years ago

Ticket created by ~vladh on ~sircmpwn/git.sr.ht

Making the following query to the git.sr.ht API:
query repositoriesByUser {
    user(username: "sircmpwn") {
        repositories {
            results {
                name
            }
        }
    }
}
results in the "hare" repository being returned 4 times and the "harec" repository 3 times.

If my understanding is correct, this particular query will be handled by the following function: https://git.sr.ht/~sircmpwn/git.sr.ht/tree/master/item/api/graph/schema.resolvers.go#L1271

I have tried to investigate under what circumstances results would be duplicated, but have not managed to figure it out. I have also not managed to replicate the issue on my local instance.

The only lead I can see is that there might be a problematic join with the "access" table, especially since both of the aforementioned repositories were previously unlisted and later became public. This is, however, just a guess, and might be wrong.

#277 Strings such as #123 should not be treated as a ticket reference inside a <pre> 2 years ago

Ticket created by ~vladh on ~sircmpwn/todo.sr.ht

The following code block:
#123
should read (with an actual pound sign):
♯123
but is erroneously expanded to a ticket reference. Presumably the solution is to not perform this expansion inside <pre> tags. There might also be other scenarios where the expansion should not be performed.

Reported by a user trying to post a core dump here: https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3Cdb8f845c-fb72-341d-a275-955935d323fa%40mailbox.org%3E