|
| 1 | +# Summary |
| 2 | + |
| 3 | +This RFC proposes moving away from the current model of fetching new releases |
| 4 | +to build, moving from using a timer to receiving webhooks. |
| 5 | + |
| 6 | +# Motivation |
| 7 | + |
| 8 | +While the current approach has worked well for us so far, it has some problems: |
| 9 | + |
| 10 | +* Running the update in a timer every 2 minutes is wasteful, as there is |
| 11 | + often a greater delay between two publishes. |
| 12 | +* Running the update in a timer every 2 minutes adds delay to getting the |
| 13 | + documentation built if the queue is empty, as the release might potentially |
| 14 | + have to wait those extra two minutes. |
| 15 | +* The way crates-index-diff stores its state (a branch in the local repo) is |
| 16 | + fragile, as it might become out of sync causing the loss of a publish. |
| 17 | +* The way crates-index-diff stores its state makes it hard to move the server |
| 18 | + installation, as the index repository needs to be moved as well. |
| 19 | + |
| 20 | +# Proposal |
| 21 | + |
| 22 | +We configure the `crates.io-index` repository to send a webhook to a new |
| 23 | +endpoint, `/_/index-webhook`, which starts a index sync in the background. The |
| 24 | +payload of the webhook is ignored, but the webhook signature is validated if a |
| 25 | +secret key is provided to the application through an environment variable. |
| 26 | + |
| 27 | +We also change [crate-index-diff] to store the hash of the last visited commit |
| 28 | +in the database instead of a local branch in the index repository: this will |
| 29 | +allow new instances to catch up immediately without the need of copying over |
| 30 | +the git repository. |
| 31 | + |
| 32 | +For this proposal to work we need to make the updates to the queue idempotent, |
| 33 | +and add a lock on the index repository in each machine to prevent the same |
| 34 | +machine from updating the same repository multiple times. |
| 35 | + |
| 36 | +# Rationale of the proposal |
| 37 | + |
| 38 | +This proposal removes the timer and implements realtime updates of the index, |
| 39 | +which does not have to happen on a specific machine if we ever move to multiple |
| 40 | +frontend servers. |
| 41 | + |
| 42 | +# Alternatives |
| 43 | + |
| 44 | +We could also switch from [crates-index-diff] to doing a full synchronization |
| 45 | +every time a new crate is published. While it would decrease the chances of an |
| 46 | +inconsistency between crates.io and docs.rs, it would impact performance every |
| 47 | +time a new crate is published. |
| 48 | + |
| 49 | +We could also do nothing: while the current system is not perfect it works |
| 50 | +without much trouble. |
| 51 | + |
| 52 | +[crates-index-diff]: https://crates.io/crates/crates-index-diff |
0 commit comments