Abort a course archive when the database dump actually fails

[drdrew42]

Description:

Problem

A failed database dump produces a "successful" archive with no database. Because WeBWorK::DB::dump_tables and NewSQL::Std::dump_table both return 1 unconditionally, archiveCourse's existing guard —

  my $dump_db_result = $db->dump_tables($dump_dir);
  unless ($dump_db_result) { ...; croak "$courseID: course database dump failed.\n"; }

— never fires. Any mysqldump failure (wrong mysqldump path, auth failure, disk full, a MariaDB column-statistics incompatibility, …) is swallowed with only a warn to the server log, and the archive is written anyway. The empty database is discovered only later, when the archive is unarchived and no tables are restored.

Fix

Make the failure propagate:

• dump_table returns 0 when mysqldump exits non-zero.
• dump_tables aggregates the per-table results and returns false if any table's dump
  failed, so archiveCourse aborts instead of writing a DB-less archive.

The existing tolerance for courses created with an earlier version of WeBWorK (which may predate some tables) is preserved: dump_tables skips tables that don't exist (via tableExists) rather than counting them as failures, so only a genuine mysqldump error aborts the archive. Because absent tables now produce no dump file, restore_tables skips missing dump files instead of restoring from a nonexistent path.

Scope note

This intentionally does not change the restore side to abort on failure — restore_tables/restore_table still return success and only warn, matching current behavior where a partial restore is preferred over none. Only the missing-file skip was added there, as a direct consequence of no longer dumping absent tables.

Testing

• Point $externalPrograms{mysqldump} at a nonexistent path (or otherwise break the dump,
  e.g. a mysqldump that rejects --column-statistics against MariaDB) and archive a course.
  • Before: archive completes "successfully"; the .tar.gz has an empty/absent
    DATA/mysqldump, and a later unarchive restores no tables.
  • After: archiveCourse dies with course database dump failed. and no archive is left behind.
• Regression: archive a normal current course — all tables dump and the archive is byte-for-byte
  equivalent to before.
• Regression: archive a course missing a newer table — that table is skipped (no longer a warn),
  the rest dump, and the archive succeeds.

[drgrice1]

Looks good. It has always bothered me that the code in the WeBWorK::Utils::CourseManagement::archiveCourse and WeBWorK::Utils::CourseManagement::unarchiveCourse methods looks at the return values of the WeBWorK::DB::dump_tables and WeBWorK::DB::restore_tables methods, and yet both of those methods always return 1. So it was a pointless check. That is still the case for the WeBWorK::Utils::CourseManagement::unarchiveCourse and WeBWorK::DB::restore_tables methods, and that should probably be changed also. But you can leave that for now. A large portion of the webwork2 code needs to be reworked to deal better with things that do not go as expected.

Most likely for the next release we are going to move away from using mysqldump for course archives, and move to a different archive format. In fact, I have already implemented that in one way. This is going to make me need to fix merge conflicts in that implementation!