test_agenda_timeslot_label_visibility fails during CI testing

[jennifer-richards]

What happened?

On the last few CI test runs, a failure in test_agenda_timeslot_label_visibility has occurred. The error is

     Datatracker 7.0.0-dev test suite, 25 March 2022 08:49:42 PDT:
======================================================================
     Python 3.6.15 (default, Dec 21 2021, 12:03:22)  [GCC 10.2.1 20210110].
FAIL: test_agenda_timeslot_label_visibility (ietf.meeting.tests_js.AgendaTests)
     Django 2.2.27, settings 'settings_sqlitetest'
The timeslot label for regular sessions should only be shown when a session is visible
     Changing TEMPLATES[0]['OPTIONS']['string_if_invalid'] to '' during testing
----------------------------------------------------------------------
     Changing INTERNAL_IPS to '[]' during testing.
Traceback (most recent call last):
     Running an SMTP test server on 127.0.0.1:2025 to catch outgoing email.
  File "/__w/datatracker/datatracker/ietf/utils/jstest.py", line 91, in tearDown
     Saving factory-boy random state to .factoryboy_random_state
    self.assertEqual("", msg)
     Creating test database...
AssertionError: '' != 'SEVERE: http://localhost:48699/meeting/we[129 chars]t)\n'
     Loading global test fixtures: names, ietf.utils.test_data.make_immutable_base_data, nomcom_templates, proceedings_templates
+ SEVERE: http://localhost:48699/meeting/week-view.html?show=ames&hide=mars&tz=us%2Feastern - Failed to load resource: the server responded with a status of 400 (Bad Request)
System check identified no issues (1 silenced).

This indicates that the week_view() view is responding with a 400 error. That view is incidental to this test which, but for this error message in the javascript console, is passing.

I have not seen this error in local testing.

What browser(s) are you seeing the problem on?

Not Applicable

Code of Conduct

• I agree to follow the IETF's Code of Conduct

[jennifer-richards]

I marked this "major" because it interferes with the CI process. I don't think it reflects a bug on the running system (though it may indicate something lurking)

[larseggert]

FWIW, the error message comes from the recent code I added that inspects whether there are unexpected things in the browser console log during a test.

[rjsparks]

Unless addressing these to allow the selenium tests to pass cleanly is dead trivial, I would like to remove that check in favor of having it in place in the eventual cypress variants of those tests.

[jennifer-richards]

I suspect it's a trivial fix once found, but I have never seen this failure locally. Tracking it down is likely to take some time so I would vote to punt to cypress.

[jennifer-richards]

#3769 removes the test