You can translate http://schema.org/language too. It's uncommon enough to be missing from Codemeta, but it doesn't mean we can't use it.

Follow journal consumption [12]

• Stop journal client [1] (export of offset needs the topics to be inactive [1'])
• Keep current offset dump just in case [2]
• Reset topics to earliest
• Restart journal client

lowering priority, as it is still possible for the crash to happen, but D7992 solves the only known source

Sentry issue: SWH-INDEXER-FB

Sorry about the change. It was by mistake.

I'm not so sure what needs to be done here.
If some fields have no values, does it have to skip it or put some default value?

workers restarting.
At least one is done and stuff are being written accordingly.

Migrate schema:

swhstorage@saam:~$ swh db --config-file indexer.yml upgrade indexer --to-version=134 --module-config-key=indexer_storage
INFO:swh.core.db.db_utils:Executing migration script '/usr/lib/python3/dist-packages/swh/indexer/sql/upgrades/134.sql'
Migration to version 134 done

With those applied ^, workers are happier now.

In T4319#86628, @ardumont wrote:

staging
...

• Checks

Although [1] [2]

[1] https://sentry.softwareheritage.org/share/issue/c224d3ab1804452e84d68170ab55590e/

[2] https://sentry.softwareheritage.org/share/issue/6e2d70aa3c4e423fa763a456130a3cc9/

staging
...

• Checks

• Backup tables that will get dropped [1]
• current deployed db version: 133 [2]
• current version to deploy: 134
• Upgrade db version [3]

Reverting:

• Stopping and disabling journal client services [1]
• D7950: Revert puppet manifest changes
• scheduler0.staging: deploy manifest changes [2]
• workers.staging: Deploy manifest changes [3]
• check everything is back to normal [4]

This needs to be reverted in waiting for [1] to be resolved.
I'll attend to it tomorrow.

Should be ready to be deployed now.