Incorrect batches identified for 'leaving', 'staying'

[christalee]

What's happening

The current batches are Spring 2 (ending 2021-06-25) and Summer 1 (ending 2021-08-06). One or more members of these batches has extended or signed up for a second batch (Summer 2), giving them an end-date of 2021-09-17. Since the batch end-dates are calculated by generating a list of all end-dates for current users, reversing that list, and using the first two dates as staying and leaving, respectively, the Summer 1 batch is listed as Leaving and the Spring 2 batch is not listed at all. See partition_current_users for details.

What should happen

The current batches should be calculated correctly as Spring 2 (2021-06-25) and Summer 1 (2021-08-06).

Thoughts

We could attach some additional logic to the end-date calculation to filter for dates that are within 6 and 12 weeks of the current date. Or we could use the existing function get_current_batches_info to identify the correct batches.

I'm not sure how this ties into the proposed switch to using start-date instead of end-date.

[jasonaowen]

To add some context: there is a recurser who attended some of their batch, and then had to reschedule, so the RC API shows them as having two stints: the current batch, and a subsequent batch. The back-end is doing the above calculation, and because this person is in the current batch (as far as the RC API is concerned), the end dates are getting thrown off.

I'm not sure how this ties into the proposed switch to using start-date instead of end-date. (#10)

This is a good concern, and after talking about it with @christalee, it sounds like it turns out to be orthogonal: the leaving/staying calculation is independent of the way that we store niceties.