Currently we queue up files for translations for each PR and submit for human and machine translation on a schedule. There are some files that Smartling's engine doesn't quite handle well / mangles it up causing our deserializers to fail. When that happens, we record what file failed and we move on to PR with the files that successfully deserialized. We keep the records for the failed files (and their jobs) in the database with a status of ERRORED.
After mulling this over and knowing the Smartling engine thing may not be fixable, it makes more sense to just discard those errored files from the database.
Advantages to this approach:
the file paths in the database may eventually become stale (when file paths change due to moving/renaming)
there's little cost in uploading the same files in subsequent runs (if queued up due to being included in a PR) and just letting them fail again and discarding them OR if the issue is fixed letting them successfully complete.
reduces need for eng to manually update database / create utility script to run to update database so files can be queued up and submitted again
simplifies workflow scripts a bit to not have to account for old records of errored files sitting around
Acceptance criteria
[x] Confirm that with this work we can close #5722
[x] Generate a list of files (full file path and file name) that are currently in ERRORED state
[x] Remove all relevant records in database for errored files
[x] Update the workflow check-translations-and-deserialize > check-job-progress.js script to discard errored files and not keep them around in the database
[x] When the check-translations-and-deserialize workflow runs and some files fail, I can easily see a list of the files (full file path) that failed in the github workflow console
Hi @roadlittledawn 👋
Thank you for filing an issue! We'll triage your issue and let you know if we have questions, and then route it to the appropriate team so we can get it solved.
Summary
Currently we queue up files for translations for each PR and submit for human and machine translation on a schedule. There are some files that Smartling's engine doesn't quite handle well / mangles it up causing our deserializers to fail. When that happens, we record what file failed and we move on to PR with the files that successfully deserialized. We keep the records for the failed files (and their jobs) in the database with a status of
ERRORED
.After mulling this over and knowing the Smartling engine thing may not be fixable, it makes more sense to just discard those errored files from the database.
Advantages to this approach:
Acceptance criteria
ERRORED
statecheck-translations-and-deserialize
>check-job-progress.js
script to discard errored files and not keep them around in the databasecheck-translations-and-deserialize
workflow runs and some files fail, I can easily see a list of the files (full file path) that failed in the github workflow consoleHelpful links