gitea: Linking issue dependencies fails (API returns 500 error)

Continuing with debugging, we found out (in chronological order)

• shorter statements work, longer don’t (so indeed, optimizing / shortening it would do improvement short-term)
• we did a minimal reproduction without Gitea nor XORM, but with PHP which works on one server and not the other (so this issue can be closed if you don’t intend to optimize anyway), the issue is with prepared statements (that’s why the manually interpolated query did work)
• and that even with a complete identical MariaDB config and db
• it seems to be a regression / changed behaviour in MariaDB between (1:10.5.15-0+deb11u1) & (1:10.5.12-0+deb11u1), the update wasn’t yet applied in the airgapped staging instance

Edit 2: The error we see from MySQL is Commands out of sync; you can't run this command now

Edit 3:

• it breaks with 1000 parameters (999 work)

What if we modify the code a bit to avoid passing all the repoIDs:

diff --git a/models/issue.go b/models/issue.go
index b1fa2d02a..1957e570c 100644
--- a/models/issue.go
+++ b/models/issue.go
@@ -1195,6 +1195,7 @@ func GetIssuesByIDs(issueIDs []int64) ([]*Issue, error) {
 type IssuesOptions struct {
        db.ListOptions
        RepoIDs            []int64 // include all repos if empty
+       RepoCond           builder.Cond
        AssigneeID         int64
        PosterID           int64
        MentionedID        int64
@@ -1289,6 +1290,10 @@ func (opts *IssuesOptions) setupSessionNoLimit(sess *xorm.Session) {
                applyReposCondition(sess, opts.RepoIDs)
        }
 
+       if opts.RepoCond != nil {
+               sess.And(opts.RepoCond)
+       }
+
        switch opts.IsClosed {
        case util.OptionalBoolTrue:
                sess.And("issue.is_closed=?", true)
diff --git a/routers/web/repo/issue.go b/routers/web/repo/issue.go
index 3ca193a15..7ab1dae01 100644
--- a/routers/web/repo/issue.go
+++ b/routers/web/repo/issue.go
@@ -2227,7 +2227,7 @@ func SearchIssues(ctx *context.Context) {
                                Page:     ctx.FormInt("page"),
                                PageSize: limit,
                        },
-                       RepoIDs:            repoIDs,
+                       RepoCond:           models.SearchRepositoryCondition(opts),
                        IsClosed:           isClosed,
                        IssueIDs:           issueIDs,
                        IncludedLabelNames: includedLabelNames,

It’s probably a very edge case, though. And it’s not breaking any data at least, only the read query. 😃

I have an idea about how to debug the problem.

Maybe we can build Codeberg-Gitea with a special flag (eg: ./gitea-codeberg my-test-issue), and use the special flag to run SearchIssues / CountIssues directly with the specialized options to trigger the bug and see output. Then we just put this test binary to production server, then test with the production database without any downtime.

If the special flag can trigger the bug, then it gives us the chance to find the root case.

If the special flag can not trigger the bug either … it must be impossible, no reason to explain it …