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...