### Description The [current code] for handling the [Remote Settings `"sync"` event](https://firefox-source-docs.mozilla.org/services/settings/index.html#events) directly adds newly created models into our list of cached models. This logic was designed very early in the project, when our conceptual idea of updating a model would be to modify the Remote Settings record in place. We later adopted a model in which we could have multiple versions of the same model within Remote Settings, and we would [retrieve only the maximum compatible version for use in Firefox](https://searchfox.org/mozilla-central/rev/8b0666aff1197e1dd8017de366343de9c21ee437/toolkit/components/translations/actors/TranslationsParent.sys.mjs#1252-1273). For example, if two version of the same model exist in Remote Settings with versions `1.0` and `1.1`, then only the `1.1` model will be used when Firefox's caches populated. The issue is that the above logic that handles the "sync" event directly adds newly created models into our cache. This means that if we publish a `1.1` version of a model, the "sync" event will include it in the cache along with the already-present `1.0` version of the model. The overall effect is that, for users who receive a sync event with an upgraded model version, they will get inconsistent translation results for that language pair until they restart their browser and the cache repopulates correctly filtering and using _only_ the `1.1` version. Since there are three records per language pair, in the best case, they get all three `1.1` records or all three `1.0` records when requesting a translation, leading to a valid translation. Unfortunately these are only 2 cases out of 20 ([6 nCr 3](https://www.wolframalpha.com/input?i=6+nCr+3)), meaning that there is a 90% chance for a user to encounter a garbage translation for that language pair until they restart their browser. There are two valid ways to fix this: 1) We could comb through our cache to search for records of the same type but a lower minor version, and remove them from the cache in favor of the new records. 2) We could just invalidate the cache and rebuild our list of records, which already does the correct thing by choosing the maximum-compatible-version record. My preference is to solve this using option 2) given that Remote Settings sync events occur at most once every 24 hours, unless manually triggered by publishing a model, which we do at most once a week. The cache currently takes between 0.1 and 0.2 seconds to fully populate. --- ### Steps to reproduce This is incredibly hard to reproduce because it involves publishing higher-minor-verison models to Remote Settings during the middle of an active session. At the time of writing, I do have the Dev and Dev (Preview) Remote Settings channels set up to reproduce this case for Spanish to English, but that will not be true forever. * Download the Remote Settings Devtools extension. * Switch to the Dev channel, clear local data, and sync. * Restart the browser. * Ensure `browser.translations.logLevel` is set to `All`. * Trigger a translation from Spanish to English. * Verify in the console logs that `1.0` version models are being used. * Switch to the Dev channel, clear local data, and sync. * DO NOT restart the browser. * Trigger a translation from Spanish to English. **Expected Behavior** The console logs should report that version `1.1` models are used. The translation is coherent. **Actual Behavior** The console logs report that version `1.0` and version `1.1` models are used. 90% of the time the translation is incoherent. ### Steps to implement * Repopulate our language models cache on Remote Settings sync events. --- ### Tests to implement * Ensure that our test cases properly cover creating, updating, and deleting models, then retrieving the expected versions.
Bug 1911890 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
### Description The [current code] for handling the [Remote Settings `"sync"` event](https://firefox-source-docs.mozilla.org/services/settings/index.html#events) directly adds newly created models into our list of cached models. This logic was designed very early in the project, when our conceptual idea of updating a model would be to modify the Remote Settings record in place. We later adopted a model in which we could have multiple versions of the same model within Remote Settings, and we would [retrieve only the maximum compatible version for use in Firefox](https://searchfox.org/mozilla-central/rev/8b0666aff1197e1dd8017de366343de9c21ee437/toolkit/components/translations/actors/TranslationsParent.sys.mjs#1252-1273). For example, if two version of the same model exist in Remote Settings with versions `1.0` and `1.1`, then only the `1.1` model will be used when Firefox's caches populated. The issue is that the above logic that handles the "sync" event directly adds newly created models into our cache. This means that if we publish a `1.1` version of a model, the "sync" event will include it in the cache along with the already-present `1.0` version of the model. The overall effect is that, for users who receive a sync event with an upgraded model version, they will get inconsistent translation results for that language pair until they restart their browser and the cache repopulates correctly filtering and using _only_ the `1.1` version. Since there are three records per language pair, in the best case, they get all three `1.1` records or all three `1.0` records when requesting a translation, leading to a valid translation. Unfortunately these are only 2 cases out of 20 ([6 nCr 3](https://www.wolframalpha.com/input?i=6+nCr+3)), meaning that there is a 90% chance for a user to encounter a garbage translation for that language pair until they restart their browser. There are two valid ways to fix this: 1) We could comb through our cache to search for records of the same type but a lower minor version, and remove them from the cache in favor of the new records. 2) We could just invalidate the cache and rebuild our list of records, which already does the correct thing by choosing the maximum-compatible-version record. My preference is to solve this using option 2) given that Remote Settings sync events occur at most once every 24 hours, unless manually triggered by publishing a model, which we do at most once a week. The cache currently takes between 0.1 and 0.2 seconds to fully populate. --- ### Steps to reproduce This is incredibly hard to reproduce because it involves publishing higher-minor-verison models to Remote Settings during the middle of an active session. At the time of writing, I do have the Dev and Dev (Preview) Remote Settings channels set up to reproduce this case for Spanish to English, but that will not be true forever. * Download the Remote Settings Devtools extension. * Switch to the Dev channel, clear local data, and sync. * Restart the browser. * Ensure `browser.translations.logLevel` is set to `All`. * Trigger a translation from Spanish to English. * Verify in the console logs that `1.0` version models are being used. * Switch to the Dev channel, clear local data, and sync. * DO NOT restart the browser. * Trigger a translation from Spanish to English. **Expected Behavior** The console logs should report that version `1.1` models are used. The translation is coherent. **Actual Behavior** The console logs report that version `1.0` and version `1.1` models are used. 90% of the time the translation is incoherent. --- ### Steps to implement * Repopulate our language models cache on Remote Settings sync events. --- ### Tests to implement * Ensure that our test cases properly cover creating, updating, and deleting models, then retrieving the expected versions.
### Description The [current code] for handling the [Remote Settings `"sync"` event](https://firefox-source-docs.mozilla.org/services/settings/index.html#events) directly adds newly created models into our list of cached models. This logic was designed very early in the project, when our conceptual idea of updating a model would be to modify the Remote Settings record in place. We later adopted a model in which we could have multiple versions of the same model within Remote Settings, and we would [retrieve only the maximum compatible version for use in Firefox](https://searchfox.org/mozilla-central/rev/8b0666aff1197e1dd8017de366343de9c21ee437/toolkit/components/translations/actors/TranslationsParent.sys.mjs#1252-1273). For example, if two version of the same model exist in Remote Settings with versions `1.0` and `1.1`, then only the `1.1` model will be used when Firefox's caches populated. The issue is that the above logic that handles the "sync" event directly adds newly created models into our cache. This means that if we publish a `1.1` version of a model, the "sync" event will include it in the cache along with the already-present `1.0` version of the model. The overall effect is that, for users who receive a sync event with an upgraded model version, they will get inconsistent translation results for that language pair until they restart their browser and the cache repopulates correctly filtering and using _only_ the `1.1` version. Since there are three records per language pair, in the best case, they get all three `1.1` records or all three `1.0` records when requesting a translation, leading to a valid translation. Unfortunately these are only 2 cases out of 20 ([6 nCr 3](https://www.wolframalpha.com/input?i=6+nCr+3)), meaning that there is a 90% chance for a user to encounter a garbage translation for that language pair until they restart their browser. There are two valid ways to fix this: 1) We could comb through our cache to search for records of the same type but a lower minor version, and remove them from the cache in favor of the new records. 2) We could just invalidate the cache and rebuild our list of records, which already does the correct thing by choosing the maximum-compatible-version record. My preference is to solve this using option 2) given that Remote Settings sync events occur at most once every 24 hours, unless manually triggered by publishing a model, which we do at most once a week. The cache currently takes between 0.1 and 0.2 seconds to fully populate. --- ### Steps to reproduce This is incredibly hard to reproduce because it involves publishing higher-minor-verison models to Remote Settings during the middle of an active session. At the time of writing, I do have the Dev and Dev (Preview) Remote Settings channels set up to reproduce this case for Spanish to English, but that will not be true forever. * Download the [Remote Settings Devtools](https://github.com/mozilla-extensions/remote-settings-devtools/releases) extension. * Switch to the Dev channel, clear local data, and sync. * Restart the browser. * Ensure `browser.translations.logLevel` is set to `All`. * Trigger a translation from Spanish to English. * Verify in the console logs that `1.0` version models are being used. * Switch to the Dev channel, clear local data, and sync. * DO NOT restart the browser. * Trigger a translation from Spanish to English. **Expected Behavior** The console logs should report that version `1.1` models are used. The translation is coherent. **Actual Behavior** The console logs report that version `1.0` and version `1.1` models are used. 90% of the time the translation is incoherent. --- ### Steps to implement * Repopulate our language models cache on Remote Settings sync events. --- ### Tests to implement * Ensure that our test cases properly cover creating, updating, and deleting models, then retrieving the expected versions.