It's possible now that #199 is fixed for cards when they're added at the end to continually stretch the range of sort_orders into a dangerous territory, approaching Number.MAX_VALUE. Or, for lots of reorders to smoosh a lot of cards into one small region. There is instrumentation in the web app to bail early if we're trying to propose a sort_order that is anywhere near the danger zone edge.
This means that ideally every so often you'd have a maintenance task that would renormalize and resmooth the range of sort_orders for all cards, from MAX_SORT_ORDER_VALUE to MIN_SORT_ORDER_VALUE.
This is challenging for two reasons: 1) while this operation is happening, you don't want any card creations, deletions, or edits that cahnge sort order. 2) it requires touching all cards, and if one batch fails, those cards could be nondeterministically shuffled between other batches.
For the first, the answer is to have a flags.disableReordering. If that document exists, then firestore security rules should reject any card creations, deletions, or sort_order changes (... unless they come from the maintenance task). The UI should also live subscribe to whether that document exists, and disable UI features. It's feasible that more than one thing might turn that on at once, so to turn it on, create the document and also create a sub-document with that processes' id and description a nd timestamp. Then when it's done, delete its sub collection item, and if there are no more left, remove the main document, too.
For the second, the answer is to do a number of individual smooth actions within a given batch. We'd split the cards up into a number of batches, smooth them out within the batches,a nd then the next set, split the first batch into a half-size start batch and a half-size end batch, which would offset the batch boundaries into the middle. Keep on osciallinag back and forth on this, until it gets smoothed enough. Because bugs in this logic could be catastrophic, during all of these actions keep a very detailed log that can be looked at if it fails.
You'd also want a similar smoothing thing to fit all of the spread into the proper range of numbers (it will ooze outside the range as new cards are added at the end of collections). This has a similar problem where it's technically possible that the far end of the cards will be out of bounds... but so will the inner edge of its batch, requiring a few oscilllations to smooth it out.
This kind of maintenance should only need to be run very, very very rarely (and maybe like once every thousand years, I haven't done the order of magnitude math). Maybe it's sufficient to have the console warnings , and then when that happens, just have the admin run the smoothly recurring task.
See also #199 for a lot of design on this, a nd see the list of unchecked actions there too
jkomoros
commented
1 year ago
It's possible now that #199 is fixed for cards when they're added at the end to continually stretch the range of sort_orders into a dangerous territory, approaching Number.MAX_VALUE. Or, for lots of reorders to smoosh a lot of cards into one small region. There is instrumentation in the web app to bail early if we're trying to propose a sort_order that is anywhere near the danger zone edge.
This means that ideally every so often you'd have a maintenance task that would renormalize and resmooth the range of sort_orders for all cards, from
MAX_SORT_ORDER_VALUEtoMIN_SORT_ORDER_VALUE.This is challenging for two reasons: 1) while this operation is happening, you don't want any card creations, deletions, or edits that cahnge sort order. 2) it requires touching all cards, and if one batch fails, those cards could be nondeterministically shuffled between other batches.
For the first, the answer is to have a
flags.disableReordering. If that document exists, then firestore security rules should reject any card creations, deletions, or sort_order changes (... unless they come from the maintenance task). The UI should also live subscribe to whether that document exists, and disable UI features. It's feasible that more than one thing might turn that on at once, so to turn it on, create the document and also create a sub-document with that processes' id and description a nd timestamp. Then when it's done, delete its sub collection item, and if there are no more left, remove the main document, too.For the second, the answer is to do a number of individual smooth actions within a given batch. We'd split the cards up into a number of batches, smooth them out within the batches,a nd then the next set, split the first batch into a half-size start batch and a half-size end batch, which would offset the batch boundaries into the middle. Keep on osciallinag back and forth on this, until it gets smoothed enough. Because bugs in this logic could be catastrophic, during all of these actions keep a very detailed log that can be looked at if it fails.
You'd also want a similar smoothing thing to fit all of the spread into the proper range of numbers (it will ooze outside the range as new cards are added at the end of collections). This has a similar problem where it's technically possible that the far end of the cards will be out of bounds... but so will the inner edge of its batch, requiring a few oscilllations to smooth it out.
This kind of maintenance should only need to be run very, very very rarely (and maybe like once every thousand years, I haven't done the order of magnitude math). Maybe it's sufficient to have the console warnings , and then when that happens, just have the admin run the smoothly recurring task.
See also #199 for a lot of design on this, a nd see the list of unchecked actions there too