Skip to content

Some RSpec jobs are time-outing

As can be seen in https://gitlab.com/gitlab-org/gitlab/-/jobs/354563576 and https://gitlab.com/gitlab-org/gitlab/-/jobs/354563702, the jobs are timeouting at approximately the same point.

By looking at the job logs, I see strange notices that start with the following test file:

3019 FixWrongPagesAccessLevel
3020 NOTICE:  trigger "trigger_4821f661bf92" for relation "application_settings" does not exist, skipping
3021 NOTICE:  trigger "trigger_97893debd1d4" for relation "design_management_versions" does not exist, skipping
3022 NOTICE:  trigger "trigger_36edafd19664" for relation "epics" does not exist, skipping
3023 NOTICE:  trigger "trigger_dd1443fbd36e" for relation "application_settings" does not exist, skipping
3024 NOTICE:  trigger "trigger_806273a4d8be" for relation "application_settings" does not exist, skipping
3025   correctly schedules background migrations
3026   project_visibility: 20, pages_access_level: 30, access_control_is_enabled: true, pages_deployed: true, resulting_pages_access_level: 20
3027     sets proper pages_access_level
3028   project_visibility: 20, pages_access_level: 30, access_control_is_enabled: false, pages_deployed: true, resulting_pages_access_level: 20
3029     sets proper pages_access_level
3030   project_visibility: 0, pages_access_level: 30, access_control_is_enabled: true, pages_deployed: true, resulting_pages_access_level: 30
3031     sets proper pages_access_level
3032   project_visibility: 10, pages_access_level: 30, access_control_is_enabled: true, pages_deployed: true, resulting_pages_access_level: 30
3033     sets proper pages_access_level
3034   project_visibility: 10, pages_access_level: 20, access_control_is_enabled: false, pages_deployed: true, resulting_pages_access_level: 30
3035     sets proper pages_access_level
3036   project_visibility: 10, pages_access_level: 20, access_control_is_enabled: true, pages_deployed: true, resulting_pages_access_level: 20
3037     sets proper pages_access_level
3038   project_visibility: 10, pages_access_level: 20, access_control_is_enabled: true, pages_deployed: false, resulting_pages_access_level: 20
3039     sets proper pages_access_level
3040   project_visibility: 0, pages_access_level: 20, access_control_is_enabled: true, pages_deployed: true, resulting_pages_access_level: 10
3041     sets proper pages_access_level
3042   project_visibility: 0, pages_access_level: 20, access_control_is_enabled: true, pages_deployed: false, resulting_pages_access_level: 10
3043     sets proper pages_access_level
3044   project_visibility: 0, pages_access_level: 20, access_control_is_enabled: false, pages_deployed: true, resulting_pages_access_level: 30
3045     sets proper pages_access_level
3046   project_visibility: 0, pages_access_level: 20, access_control_is_enabled: false, pages_deployed: false, resulting_pages_access_level: 10
3047     sets proper pages_access_level
3048 NOTICE:  trigger "trigger_806273a4d8be" for relation "application_settings" does not exist, skipping
3049 NOTICE:  trigger "trigger_dd1443fbd36e" for relation "application_settings" does not exist, skipping
3050 NOTICE:  trigger "trigger_84853438aac0" for relation "epics" does not exist, skipping
3051 NOTICE:  trigger "trigger_97893debd1d4" for relation "design_management_versions" does not exist, skipping
3052 NOTICE:  trigger "trigger_4821f661bf92" for relation "application_settings" does not exist, skipping

By looking at the traces being reported live, I can see that each of these notice lines take some time to appear, meaning that the operation performed underneath itself take some time...