Gitea can't automatically create table for session storage in MySQL database

[Ziars]

• Gitea version (or commit ref): 1.8.2
• Git version:
• Operating system:
• Database (use [x]):
  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite
• Can you reproduce the bug at https://try.gitea.io:
  • Yes (provide example URL)
  • No
  • Not relevant

Greetings!

I'm using Gitea v.1.8.2 in my setup and have recently ran into strange behaviour: when changing session storage from files to MySQL Gitea doesn't create the needed table in the database. All other tables are being created normally, though (if database was initially empty). Here are some errors from logs, that could be seen right after changing session storage in clean installation from file to MySQL and restarting:

May 23 22:09:31 testing gitea[3984]: [Macaron] 2019-05-23 22:09:31: Started GET /metrics for 123.123.123.123
May 23 22:09:31 testing gitea[3984]: [Macaron] PANIC: session/mysql: error checking existence: Error 1146: Table 'testing.session' doesn't exist
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/session/mysql/mysql.go:152 (0xa4cdc3)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/modules/session/virtual.go:67 (0xb3563a)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/session/session.go:290 (0x9e70c0)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/session/session.go:160 (0x9e8379)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/context.go:79 (0x9c8580)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/inject/inject.go:157 (0x9998e0)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/inject/inject.go:135 (0x99960a)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/context.go:121 (0x9c86d9)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/context.go:112 (0x9da13f)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/recovery.go:161 (0x9da12d)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/logger.go:40 (0x9cc373)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/inject/inject.go:157 (0x9998e0)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/inject/inject.go:135 (0x99960a)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/context.go:121 (0x9c86d9)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/context.go:112 (0x9d9460)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/logger.go:52 (0x9d944b)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/logger.go:40 (0x9cc373)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/inject/inject.go:157 (0x9998e0)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/go-macaron/inject/inject.go:135 (0x99960a)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/context.go:121 (0x9c86d9)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/router.go:187 (0x9db386)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/router.go:294 (0x9d4e9d)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/gopkg.in/macaron.v1/macaron.go:220 (0x9cd74c)
May 23 22:09:31 testing gitea[3984]: /go/src/code.gitea.io/gitea/vendor/github.com/gorilla/context/context.go:141 (0xcdbd9a)
May 23 22:09:31 testing gitea[3984]: /usr/local/go/src/net/http/server.go:1995 (0x6ef443)
May 23 22:09:31 testing gitea[3984]: /usr/local/go/src/net/http/server.go:2774 (0x6f2717)
May 23 22:09:31 testing gitea[3984]: /usr/local/go/src/net/http/server.go:1878 (0x6ee400)
May 23 22:09:31 testing gitea[3984]: /usr/local/go/src/runtime/asm_amd64.s:1337 (0x4620e0)
May 23 22:09:31 testing gitea[3984]: [Macaron] 2019-05-23 22:09:31: Completed GET /metrics 500 Internal Server Error in 833.331�s

It's hard to find anywhere the right table structure needed for session table. As workaround I'm creating the table manually on each of mine Gitea instances (using the query from documentation of go-macaron framework):

CREATE TABLE IF NOT EXISTS `database_name`.`session` ( `key` CHAR(16) NOT NULL, `data` BLOB, `expiry` INT(11) UNSIGNED NOT NULL, PRIMARY KEY (`key`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;"

Is this a normal behaviour? If not - can u please fix this in future releases (considering that there are no problems with creating all other tables automatically)?

Steps to reproduce

1. There should be no session table in the database being used
2. Switch session storage to MySQL in Gitea cfg (app.ini), for example:

PROVIDER        = mysql
PROVIDER_CONFIG = testing:somepassword@tcp(srv-mysql:3306)/testing

3. Restart Gitea for changes to take effect

[lunny]

We need a table named session with three columns named key,data,expiry .

[techknowlogick]

Should this be handled upstream?

[zeripath]

Yes however, it may be that we need to provide then with a patch and or fork.

[xoxys]

This seems to be still causing issues if someone wants to use a DB as session provider: [Macaron] PANIC: session/postgres: error checking existence: pq: relation "session" does not exist. Is there any update? Even if this could not be fixed easily upstream (I guess that means go-macaron?) why could gitea not take care of it and prepare a session table like every other required table, ready to use if someone configures a DB session provider?

[zeripath]

Although we could get the macaron session provider software to create the db table - I think we'd be better off creating a Xorm session provider that just creates the session table as appropriate.

[xoxys]

Doing it this way, would it be possible to re-use the specified DB parameters from the [database] section instead of adding a (somehow duplicated) PROVIDER_CONFIG?

[zeripath]

yes