Possible issue with submitting objects with limited/no visibility

[talister]

Attempting to schedule 2012 PG6 on June 13 for obs on 2021-06-16 caused 2 issues:

1. Updating the airmass constraint from 1.74 to 2 reset the window from 2021-06-15T23:00:00 -> 2021-06-15T23:30:00 to 2021-06-14T23:00:00 -> 2021-06-14T23:12:00 resulting in no window (could be a time of year corner case as we are close to the winter solstice in Chile and the short window were the start of night begins at ~23:00 the previous night)
2. Don't recollect exactly what params were set to but submitting produced a 500 Server Error and:

[13/Jun/2021 22:03:21] ERROR Internal Server Error: /schedule/51832/confirm/
ERROR:django.request:Internal Server Error: /schedule/51832/confirm/
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/django/core/handlers/exception.py", line 47, in inner
    response = get_response(request)
  File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 188, in _get_response
    self.check_response(response, callback)
  File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py", line 311, in check_response
    "instead." % name
ValueError: The view core.views.ScheduleSubmit didn't return an HttpResponse object. It returned None instead.

so it seems there is a error return case, possibly coming back from the Obs Portal which is not being caught and reported to the user properly and is instead causing a crash

[jchate6]

Do you recall about what time you tried to submit the observation and how long the observing block was?

[talister]

Do you recall about what time you tried to submit the observation and how long the observing block was?

22:03 UTC (have added time into issue above) and the block was the NEOx-calculated 20 mins I think (want to say form showed 0.5 hrs of vis at airmass but could well be mis-remembering)

[jchate6]

This seems to be a result of the fact that we update the utc_date to the midpoint of the current window under certain circumstances.
Basically, because the start of 2021-06-16 is 2021-06-15T23:00 right now, and the object is only visible for 30 min, the midpoint of the current window is in 2021-06-15. Editing the airmass resets the windows using the midpoint to determine the date bumping the window back again to 2021-06-14.
For single site observations, we have form validation in place to prevent modifying the window outside of the visibility range for the current utc_date. There are a lot of reasons for this, but ultimately it comes down to us trying to allow neoexchange to be smart enough to guess the "proper" window that is meant when we just give it a date while not misleading the user into thinking the object will be visible during times when it is not.

I think this can be "fixed" by being more careful about when utc_date is changed, and how.
In the mean time, these observations should be able to be scheduled by using a start date of 2021-06-17, changing the airmass to 2, then submitting. (Alternatively, using a generic 1m and changing the window to only include 2021-06-15T23:00-24:00 will accomplish the same thing without any time issues).