roachtest: backup-restore/round-trip failed

[cockroach-teamcity]

roachtest.backup-restore/round-trip failed with artifacts on release-24.1.0-rc @ 5e4ca9e26f1a25681de9c944298cfa139c344466:

(monitor.go:154).Wait: monitor failure: full command output in run_062053.535167405_n4_COCKROACHRANDOMSEED1.log: COMMAND_PROBLEM: exit status 1
test artifacts and logs in: /artifacts/backup-restore/round-trip/run_1

Parameters:

• ROACHTEST_arch=amd64
• ROACHTEST_cloud=gce
• ROACHTEST_coverageBuild=false
• ROACHTEST_cpu=4
• ROACHTEST_encrypted=true
• ROACHTEST_metamorphicBuild=false
• ROACHTEST_ssd=0

Help

See: roachtest README

See: How To Investigate (internal)

See: Grafana

Same failure on other branches

• roachtest: backup-restore/round-trip failed #124333 roachtest: backup-restore/round-trip failed [C-test-failure O-roachtest O-robot T-disaster-recovery branch-master]

/cc @cockroachdb/disaster-recovery

This test on roachdash | Improve this report!

Jira issue: CRDB-38857

[msbutler]

this is failing on the schema change workload but the logs are not giving me any clues as to why. This opaque failure feels like the same issue as #124333, which i chalked up to some test infra bug, but the logs here do not indicate that any schema change object was acted upon by systemTableWriter. Handing this over to sql schema for a look.

[rafiss]

error is

{
 "workerId": 0,
 "clientTimestamp": "06:21:10.839923",
 "ops": [
  "BEGIN",
  {
   "sql": "ALTER TYPE schema_w4_140.enum_w1_154 DROP VALUE 'a'"
  },
  {
   "sql": "CREATE FUNCTION schema_w3_112.udf_w0_173(i INT8, j INT8)\n\tRETURNS VOID\n\tLANGUAGE SQL\n\tAS $$ SELECT NULL $$"
  },
  {
   "sql": "CREATE SEQUENCE IF NOT EXISTS schema_w3_112.seq_w0_174"
  },
  {
   "sql": "DROP SCHEMA \"schema_w4_140\" CASCADE"
  },
  "COMMIT"
 ],
 "expectedExecErrors": "",
 "expectedCommitErrors": "",
 "message": "***UNEXPECTED COMMIT ERROR; Received an unexpected commit error: ERROR: transaction committed but schema change aborted with error: (42704): type with ID 194 does not exist (SQLSTATE 42704)",

this is fixed by #123562 but we are not backporting that to this RC branch.