sbp commented on issue #1367: URL: https://github.com/apache/tooling-trusted-releases/issues/1367#issuecomment-4895486502
We originally wrote to the database first and then the filesystem, because the filesystem part needed data computed in the database part. In d607d31207165bafed99b6b9c83d4ddf527e10f1 (2025-09-08) I made it possible to compute the destination path without having to commit to the database, and that made swapping the order possible. In f177e1b34e2d85adeaa8ed3ed9929bb49167f9cf (2025-11-07) I did the swap, writing to the filesystem first and then the database. Why did I do that? Because queueing the announcement email is part of the database block, so if the filesystem part had a problem then the announcement email would be pointing to a release that failed to happen. The present issue points out that this new order still has a problem, because the filesystem part (which now comes first) is _destructive_. If the database part fails, we can't roll back the filesystem. We could resolve this by moving the destructive part of the filesystem write out to after the database block, so we would do all the moving of the published revision on the filesystem, then all of the writing to the database, and then all of the deletion of prior revisions on the filesystem. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
