fix: remove session activity updated event as it is not needed

[mohsinht]

Why is this change needed?: https://www.loom.com/share/d6b407d072d54d9b86b20f4830889d79

Problem:

• SessionActivityUpdated event listens to the changes in Activity. But this has a drawback. The changes to an activity are applied one at a time. For example, when we fill a form, then a sub-activity is added to the Activity document. Which triggers ActivityUpdated event.
• At this stage when sub-activity is added, the subscription sends a message to client that this Activity has been updated with some new data. Client updates the cache with the new Activity data.
• Then the ActivityCompleted event is triggered as Activity is marked as 'Done'.

But what happens if ActivityUpdated event happens AFTER ActivityCompleted ? Then the activity is first marked as Done by the ActivityCompleted event and then the activity is marked Active by the ActivityUpdated event. This leaves the Hosted Pages app in a wrong state.

Solution:

• Remove ActivityUpdated event from the app as it is not required. We only need to listen to statuses of Activities, not their other properties.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
hosted-pages	✅ Ready (Inspect)	Visit Preview	Jul 24, 2023 9:06pm

[rahulkeerthi]

Your reasoning makes sense to me. Is this true for all actions, aside from the built in ones? As I understand we don't have any activities today that rely on real-time sync with the backend (e.g. user input only updates the activity state, but does not also complete it). In other words, aside from 'leaving', users can only complete activities once presented with them in our apps -- there is no partial state for an activity. I don't expect that to change for a while yet, though I could see form visibility condition evaluation moving to a subscription to make updates faster. Even in that case, it wouldn't be the activity that is updating

Interested in @FlavioF thoughts here too

[rahulkeerthi]

I'd love to set up a checkly test that can be run X times against a staging (or even preview) build of AHP to test for regressions