At the last Data-WG meeting (please find meetings notes here), we discussed how we’d like to see the events lifecycle @BrianMesick has already created an issue to address that data-wg #23.
The riskiest part where events could be lost is frontend legacy → MFE transition.
In our RaccooGand experience with the native OpenedX events, we’ve noticed that edx.ui.lms.link_clicked disappeared during the courseware transition to MFE.
On the data-wg, we’ve discussed our expectation of events transferring to the MFE. And the first thoughts are the following:
existed events should be replicated in the MFE by default, even if it is not clear whether they are needed or not;
changes to the existing events would require documenting (e.g. ADR) and versioning;
removing events should be passed through the deprecation process.
We would be very glad to hear what frontend-wg thinks about that question and involve @arbrandes, @djoy, and everyone interested in the discussion of the lifecycle of events in Open edX.
Speaking from the edX/2U side, we’ve definitely felt the pain of not being rigorous enough around preserving/migrating events. Missing/different events have come up in several MFE replatforming projects now, and in my opinion we still lack a strong process to ensure it doesn’t happen again.
The three thoughts/principles you outlined above, @idegtiarov, generally make sense to me and I’d support it. The hard part is going to be ensuring those principles get respected! There’s only so many more MFE replatforming efforts left, I suppose, but it’d be nice not to have any more surprises w/r/t our events.
I’m wondering if this can be run through the product working group in some respects… I’d expect that the PWG would be aware of upcoming replatforming and would be able to advocate through the proper channels (product and the owning team?) to make sure that auditing and preserving events is including in our “definition of done” for that project.
Definitely open to suggestions here. This is mostly my Monday morning hot take.
Worth mentioning - there’s a new Course Home MFE that’s nearly complete and being rolled out by edX. We should make sure we’ve done the right thing there.
I think that @arbrandes suggestions are a great start, but from painful personal experience it can be hard to tell when an event if being emitted / changed / etc. For instance when the calls to send events are wrapped in convenience methods or implicit events. The flexibility of the system to do things like send events to Segment and have Segment configured to forward them back to the LMS tracking logs can make understanding of the intended use of events even more complicated to understand.
I’ve been thinking of various ways that we could automate change management and documentation of events, but all of them so far involve massive refactoring of how events are emitted on both the server and client side. I’d love to do a working group session on that in the new year, but for now I’ll work with @arbrandes to make sure then checklist and test plan are updated, and check in about the Course Home MFE to find out the state of events in it.
It’s probably also worth an ADR to cover the 3 points @idegtiarov mentioned above, but I’m not sure off hand where that would go.
I’ve updated the MFE checklist to be explicit that events count as “functionality” and need to either be carried over or run through the DEPR process. I’ve set up a reminder to check in with BTR for the Palm release cycle to get event testing on their list, which gives me a few months to figure out how they can possibly test that.
@djoy I’m not able to find a new Course Home MFE on the openedx side of the house. Are these changes going into frontend-app-learning or is this a new repo? Is there someone we can follow up with on this?
The checklist for the created/updated MFE and test cases to check items are not missed looks great, hope it works ))
Additional automated change management and documentation of the events could help us with the event lifecycle and I would be glad to join a working group discussion in the new year. BTW that possible change goes a little bit contradictory with the @e0d proposal embargo native events so we could discuss it either.
@djoy aha thanks, that makes more sense! I’ll poke around in there.
@idegtiarov thanks for the reminder on that other thread. I’ve replied over there, but where we landed on it was that there’s value in the native events as a single source for transformation into other output types (xAPI / Caliper currently, but potentially others if there is a future need).
My example should not be taken as a to-do action, more like a real-life example of the event transformation/migration inside the codebase that could probably help us to create the document of the event lifecycle.
Sorry, if the keywords MFE and incident bring some wrong triggers with themself ))
Ah, gotcha! And yes, I agree it’s a good example of the type of thing we’re discussing here.
In this case the maintainers fixed the problem before it could be raised as part of the community test plan. We could point to it as what we’d like to happen when developers adhere to the MFE checklist, which now contains an explicit reference to events: by the time somebody actually checks an MFE against the list, they find that there’s nothing missing.
