Summary
Add automated coverage in Liberdus/client-testing for the optimistic reaction set rollback flow implemented on web-client-v2 branch phase-8-reaction-set-rollback.
Reference PR:
Scope
We want E2E coverage for the phase 8/9 reaction behavior on that branch:
- optimistic outgoing reaction
set shows immediately
- immediate inject failure rolls the reaction back to the previous emoji
- pending explicit failure rolls the reaction back to the previous emoji
- pending timeout rolls the reaction back to the previous emoji
- pending success keeps the new emoji and removes the hidden fallback state
- reaction
remove remains non-optimistic
Suggested Test Setup
Use a message that already has an existing reaction from the sender, for example:
- sender reacts
😀
- sender changes reaction to
🔥
That makes the expected behavior easy to verify:
- optimistic state:
🔥
- failure rollback:
😀
- success state:
🔥
What To Verify
From the UI perspective, verify:
- message chip shows the effective emoji only
- reaction picker active state matches the effective emoji
- chat-list preview/order updates correctly for reaction activity
- failure paths visibly revert to the old reaction
- success path leaves the new reaction in place
If the client-testing harness supports test hooks or network stubbing, cover these result paths:
- inject failure
- pending receipt success
false
- pending receipt timeout / no transaction
- normal success
Notes
The web-client-v2 branch also has a local testing note and optional testing patch here:
data_structures_flow/phase-8-9-reaction-testing.md
data_structures_flow/phase-8-9-reaction-testing.patch
Those files are not intended as production changes, but they describe the exact scenarios and expected outcomes.
Summary
Add automated coverage in
Liberdus/client-testingfor the optimistic reactionsetrollback flow implemented onweb-client-v2branchphase-8-reaction-set-rollback.Reference PR:
Scope
We want E2E coverage for the phase 8/9 reaction behavior on that branch:
setshows immediatelyremoveremains non-optimisticSuggested Test Setup
Use a message that already has an existing reaction from the sender, for example:
😀🔥That makes the expected behavior easy to verify:
🔥😀🔥What To Verify
From the UI perspective, verify:
If the client-testing harness supports test hooks or network stubbing, cover these result paths:
falseNotes
The
web-client-v2branch also has a local testing note and optional testing patch here:data_structures_flow/phase-8-9-reaction-testing.mddata_structures_flow/phase-8-9-reaction-testing.patchThose files are not intended as production changes, but they describe the exact scenarios and expected outcomes.