sbp opened a new issue, #94:
URL: https://github.com/apache/tooling-trusted-release/issues/94
The current code creates a revision row and then adds it to the database
before it even creates the new revision directory. If somebody else creates
another new revision meanwhile, there may be an error. If they created it when
the files are being copied, they'd end up with a partial or even corrupted
revision from the old revision that's being copied into place. Then there's the
operation that the new revision is being created for, which creates an extra
window of opportunity for such a race.
This is difficult to solve without locking because we have database state
and filesystem state, and we can't move both atomically together. The
difficulty is that we're effectively reserving a new revision number, and we
need to make clear that it's been allocated. If, for example, we just had the
context manager not add the revision until exiting, then another request might
try to create the same revision.
The best solution is probably to have a `finished`, `frozen`, `immutable`
property on `Revision` which is only set when the context manager is exiting.
The existence of the `Revision` with the property set to `False` acts as a
lock. A mutable revision should probably then mean "you shall allocate above
me, but you shall not view me, and you shall not copy me".
It's still not clear what should happen if a revision is mutable when trying
to create a new one from it. We could either show an error, or use the previous
immutable revision. Note that the numerically previous revision is not
necessarily mutable because multiple users may be creating a new revision
simultaneously.
Users aren't being shown new revisions in progress ("you shall not view
me"), so they shouldn't be surprised that the new revision they're making isn't
copying from it ("you shall not copy me"). Therefore we should use the previous
immutable revision when creating a new revision, instead of showing an error.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@tooling.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tooling.apache.org
For additional commands, e-mail: dev-h...@tooling.apache.org
