[adapter] Ignore deletions for objects that are always wrapped #7174
Conversation
If an object has always existed in a wrapped state and is eventually deleted, don't included it among the deleted (and therefore modified) objects in the effects for the transaction that deletes its ID. Test Plan: Updated an existing unit test to confirm the values for `modified_at_versions` after deleting an object that was always wrapped
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎ |
| SequenceNumber::new() | ||
| // This object was not created this transaction but has never existed in | ||
| // storage, skip it. | ||
| continue; |
There was a problem hiding this comment.
isn't the Ok(Some(...)) case also questionable - if an object did exist in the store, and then was wrapped, and then deleted, is it approriate to use the last version that existed before being wrapped?
There was a problem hiding this comment.
also, i'm slightly concerned about how this could mask a bug in which parent_sync isn't updated, but maybe there's not much we can do about that.
There was a problem hiding this comment.
I think there's an argument to be made that because wrapping is considered a form of deletion, if the object was not in by_value_objects, this deletion should be entirely ignored (i.e. advocating for getting rid of the use of parent sync altogether), but things are set-up this way because in practice, it's useful to know when the object is gone for good vs just hidden. That is a deeper subject than the thesis of this PR though.
There was a problem hiding this comment.
isn't the Ok(Some(...)) case also questionable - if an object did exist in the store, and then was wrapped, and then deleted, is it approriate to use the last version that existed before being wrapped?
I'm not sure what else you would suggest?
IIRC correctly, we used to set it to MAX - 1 instead of previous_version, but that feels even more confusing.
If you conceptually think of the version as being a field of the object (even though that isn't the case in Move), the previous_version is the consistent behavior.
Though definitely open to suggestions here.
also, i'm slightly concerned about how this could mask a bug in which parent_sync isn't updated, but maybe there's not much we can do about that.
That is a potential issue, yes. One thing we have discussed doing is forming a write-ahead, crash-recovery log of Txn => ObjectID => Version which would indicate the version used as an input in this transaction in the case that this transaction is being reprocessed (for whatever reason). We could also populate that table for this parent sync case, which I think should help prevent any bugs with the parent_sync, but maybe
There was a problem hiding this comment.
in the case that this transaction is being reprocessed
@tnowacki We won't have to worry about that - the current and future plan for execution recovery is that we only ever execute once, then right the temporary store + effects atomically to a recovery "log" before updating the store. If the store updates are interrupted, we re-read the recovery log rather than re-executing. Otherwise there is no way to be correct wrt dynamic child loading as far as I can see.
| SequenceNumber::new() | ||
| // This object was not created this transaction but has never existed in | ||
| // storage, skip it. | ||
| continue; |
There was a problem hiding this comment.
isn't the Ok(Some(...)) case also questionable - if an object did exist in the store, and then was wrapped, and then deleted, is it approriate to use the last version that existed before being wrapped?
I'm not sure what else you would suggest?
IIRC correctly, we used to set it to MAX - 1 instead of previous_version, but that feels even more confusing.
If you conceptually think of the version as being a field of the object (even though that isn't the case in Move), the previous_version is the consistent behavior.
Though definitely open to suggestions here.
also, i'm slightly concerned about how this could mask a bug in which parent_sync isn't updated, but maybe there's not much we can do about that.
That is a potential issue, yes. One thing we have discussed doing is forming a write-ahead, crash-recovery log of Txn => ObjectID => Version which would indicate the version used as an input in this transaction in the case that this transaction is being reprocessed (for whatever reason). We could also populate that table for this parent sync case, which I think should help prevent any bugs with the parent_sync, but maybe
If an object has always existed in a wrapped state and is eventually deleted, don't included it among the deleted (and therefore modified) objects in the effects for the transaction that deletes its ID.
Test Plan
Updated an existing unit test to confirm the values for
modified_at_versionsafter deleting an object that was always wrapped