Page MenuHomePhabricator

[lib] Introduce delete message spec
AcceptedPublic

Authored by tomek on Fri, Mar 28, 5:45 AM.
Tags
None
Referenced Files
F5117576: D14511.id47610.diff
Wed, Apr 2, 7:38 PM
Unknown Object (File)
Wed, Apr 2, 1:08 AM
Unknown Object (File)
Wed, Apr 2, 12:11 AM
Unknown Object (File)
Tue, Apr 1, 12:01 AM
Unknown Object (File)
Mon, Mar 31, 2:48 PM
Unknown Object (File)
Mon, Mar 31, 2:48 PM
Unknown Object (File)
Mon, Mar 31, 7:59 AM
Unknown Object (File)
Sun, Mar 30, 10:02 PM
Subscribers
None

Details

Reviewers
kamil
ashoat
Summary

This spec is mostly inspired by the one for EDIT_MESSAGE

https://linear.app/comm/issue/ENG-10326/add-a-spec-for-the-delete-message-message

Depends on D14510

Test Plan

Flow. Tested later in the stack.

Diff Detail

Repository
rCOMM Comm
Branch
delete-messages
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

tomek requested review of this revision.Fri, Mar 28, 6:04 AM
ashoat added inline comments.
lib/shared/messages/delete-message-spec.js
108–109

Interesting that you use FUTURE_CODE_VERSION here but you used NEXT_CODE_VERSION earlier in the stack. I guess we want to introduce the migrations earlier than we want the messages unshimmed? Is there a downside to introducing the unshimming at the same time?

This revision is now accepted and ready to land.Fri, Mar 28, 6:45 AM
tomek retitled this revision from [lib] Introduce a message spec to [lib] Introduce delete message spec.Thu, Apr 3, 8:16 AM
lib/shared/messages/delete-message-spec.js
108–109

I think the safest approach is to use FUTURE_CODE_VERSION initially and then replace it with NEXT_CODE_VERSION in a diff that e.g. performs a migration. By taking this approach we're making sure that there's no chance to introduce an issue by landing only a part of the stack. Update the earlier diff with FUTURE_CODE_VERSION.