Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • add celery to the ecommerce stack.
  • provision a durable message queue and worker processes for processing order fulfillments as celery tasks.
  • optionally (see below): introduce a 'pending' state to the LMS' notion of course enrollments.  this is intended to facilitate a better user experience under potential side effects introduced by asynchronous processing , but may not be strictly necessary(see below).

Considerations

Development / Testing Impact

...

On the downside, however, this change will introduce the possibility that a user may visit their dashboard after successfully completing a transaction via Otto but before their order (course enrollment) has been fulfilled.  This is particularly likely with Otto checkouts involving honor-mode (free) seats, since the user will be instantly redirected to their dashboard on completion of the order, and there's a good chance the fulfillment task will not yet have successfully completed before that time.

These are two options to To mitigate this problem:

...

, we should start to create enrollments with a new status of 'pending' when registration happens via the LMS, and have the enrollment api clear this status when the user's enrollment is made active during fulfillment.  This will permit us to display the enrollment immediately on the dashboard, with a link into the course disabled and accompanied by an indication that the seat is not yet available.  This will reassure the user that their request has been acknowledged by the system and is in progress. 

...

While the user is viewing their dashboard, a script on running in the browser would check the server frequently for updates to the pending status, which would generally be expected to become active within a second or two - the client could then refresh the display in-place and permit the user to the fully active

...

enrollment

...

.

...

While more work, a benefit of option 1 above is that its pattern can be applied more broadly to future product/fulfillment patterns not yet implemented in Oscar, and it should work equally well with paid-only seats.  At present, paid-only seats will not appear on a dashboard until the payment provider has notified us of successful payment, and the ensuing user redirection to a receipt page usually provides the time buffer needed to ensure enrollment gets fulfilled.  Having a pending mode will remove the need to rely on this assumption, and permit us to provide a sane user experience for products that may have more time-consuming fulfillment requirements.