final rebase

remove unnecesssary Thick thread type import

rebase

keep op time field consistent in edit entry operation. rename lastUpdatedTo field to time

update useDeleteEntry to await sending DM op

review feedback

review feedback

review feedback

rebase

Abandoning. Following discussion in https://linear.app/comm/issue/ENG-8745/create-dmoperations-for-restoreentrymessageinfo#comment-8eb5b44d, this is no longer necessary

update lastUpdatedTime in delete entry op to be time

Requesting review. Timestamp check included in future diff and will prioritize landing this by organizing code in a future diff

Rerequesting review

In D13340#375962, @tomek wrote:

It is a bit confusing to see all this info being sent while deleting an entry. It might be invalid when one user edits an entry while someone else deletes it.

The proper solution would require:

1. Modifying the payload to contain just the ID of the deleted entry without too many details
2. Introducing a util that provides all the entry infos
3. Introducing a separate timestamp for deleted property

This will take some time, and we're short on it, so we should search for a simpler solution.
What we can do for now, is to keep the current approach and introduce a lastUpdatedTime timestamp check.

rebase

add backup window

review feedback

addressed apostrophes and unneeded newline in latest rebase

typo. accidental uppercase

review feedback

rebase

review feedback

switch around

review feedback

update latest version to block on with default

review feedback

feedback

rebase

review feedback

Looks good to me. There shouldn't be any issues with load balancer health checks correct?

There's another possible solution I didn't think of until now. We can possibly fork non-master processes earlier than the migration, start their express servers with only health checks, and then stall? This would have the added benefit of having multiple processes handling health check requests. Unsure if this is feasible or more desirable than my current solution

In D13172#373294, @ashoat wrote:

It's unclear to me why you need to stop the Express server at all. Why not take a similar approach to D13213?

In D13213#373288, @ashoat wrote:

In D13172, you had to stop the Express server after starting it, which forced you to introduce a new dependency (stoppable). Why was that not necessary here?

In D13209#372882, @varun wrote:

if a dev is introducing a new migration how will they know which migrationType variant to use? can we instead introduce an optional field in Migration to override the default behavior?

review feedback