Gitlab mirgration: invalid memory address or nil pointer

[anbraten]

Gitea Version

1.17.0+dev-47-g8038610a4

Git Version

No response

Operating System

No response

How are you running Gitea?

services:
        gitea-database:
          image: postgres:12.6-alpine
          restart: always
          environment:
            POSTGRES_USER: gitea
            POSTGRES_PASSWORD: "{{ gitea_database_password }}"
            POSTGRES_DB: gitea
            PGDATA: /var/lib/postgresql/data/pgdata
          volumes:
            - /var/lib/postgresql/gitea/pgdata:/var/lib/postgresql/data/pgdata

        gitea:
          image: gitea/gitea:{{ gitea_version }}
          restart: always
          ports:
            - "3022:22"
          volumes:
            - /opt/gitea:/data
            - /etc/timezone:/etc/timezone:ro
            - /etc/localtime:/etc/localtime:ro
          depends_on:
            - gitea-database
          environment:
            USER_UID: 1000
            USER_GID: 1000
            GITEA__database__DB_TYPE: postgres
            GITEA__database__HOST: gitea-database:5432
            GITEA__database__NAME: gitea
            GITEA__database__USER: gitea
            GITEA__database__PASSWD: "{{ gitea_database_password }}"
          networks:
            - default
            - web-proxy

Database

PostgreSQL

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/anbraten/17a91226dbca85be5dae8a9541da4523

Description

Getting an error while gitea tries to migrate pull-requests from Gitlab:

PANIC during runMigrateTask[3] by DoerID[4] to RepoID[3] for OwnerID[5]: runtime error: invalid memory address or nil pointer dereference

Screenshots

No response

[zeripath]

gitea/services/migrations/gitlab.go

Line 649 in 726715f

CreatedAt: *approvals.UpdatedAt,

Is where the stacktrace it's pointing to.

Clearly in this case the approvals.UpdatedAt pointer is nil and so dereferencing it produces a npe.

approvals itself must not be nil as the other lines would fail. Clearly the code here has assumed that this value would always be set even though the pointer should have indicated that it was potentially not.

I guess the simplest thing to do is to check if the time is present before dereferencing it but this likely means that the rest of the migration code has assumed things that it probably shouldn't have - so it could do with a check-up.