Operations are grouped into epochs. Each epoch begins at a specific base commit. When persisting operations to a database, we want to associate epochs with their base commit so we can determine the active epoch for a given branch.
When we receive an operation with an unknown epoch id, we want to create that epoch lazily on the server. Usually, the first operation for a new epoch that we'll receive is the EpochStart operation, which includes the head commit's OID. However, we want it to be possible for the server to treat operations as opaque binary, and we don't necessarily want to enforce a strict order on how operations for a given epoch are processed and stored by the server. For these reasons, we're deciding to send the epoch head OID to the server with each operation. This will make it possible to create a new epoch and associate it with the correct start commit regardless of the order in which we process operations for storage.
This will unfortunately add an extra 20 bytes of overhead per operation that we send to the server, which most of the time will be redundant. If we think we can guarantee that the EpochStart operation will always be processed first, we can revisit this. For now it seems easier to relax that constraint.
Operations are grouped into epochs. Each epoch begins at a specific base commit. When persisting operations to a database, we want to associate epochs with their base commit so we can determine the active epoch for a given branch.
When we receive an operation with an unknown epoch id, we want to create that epoch lazily on the server. Usually, the first operation for a new epoch that we'll receive is the
EpochStart
operation, which includes the head commit's OID. However, we want it to be possible for the server to treat operations as opaque binary, and we don't necessarily want to enforce a strict order on how operations for a given epoch are processed and stored by the server. For these reasons, we're deciding to send the epoch head OID to the server with each operation. This will make it possible to create a new epoch and associate it with the correct start commit regardless of the order in which we process operations for storage.This will unfortunately add an extra 20 bytes of overhead per operation that we send to the server, which most of the time will be redundant. If we think we can guarantee that the
EpochStart
operation will always be processed first, we can revisit this. For now it seems easier to relax that constraint./cc @probablycorey @as-cii