Recovering missing jobs/workspaces after CryoSPARC v5 database recovery – project partially restored

Subject: Recovering missing jobs/workspaces after CryoSPARC v5 database recovery – project partially restored

Hello CryoSPARC team,

We’re looking for advice on recovering a project after a server failure. Most projects recovered successfully, but one large project (P6) appears to have been only partially restored.

Environment

  • CryoSPARC v5.0.6

  • Project directories stored on NFS:

    /mnt/xxxxx/CS-fabio-projects-2023-1
    
    
  • CryoSPARC database and software were on the login node.

What happened

Our cluser login node experienced a hardware failure, requiring restoration of the CryoSPARC installation and database.

We restored the CryoSPARC master and database from backup and performed database recovery using:

cryosparcm recover -f cryosparc_instance_config_2026_07_04_07h23.tar

The recovered CryoSPARC instance is functional:

  • users can log in

  • new jobs run successfully

  • most projects were recovered correctly

However, one user’s project (P6) is missing most workspaces/jobs created after approximately the end of May 2026.

Interestingly, another user’s July 2026 jobs are present after recovery, so the problem appears to be specific to P6 rather than a general recovery issue.

What we found

The project directory still exists and appears complete.

For example, recent jobs such as J5297 still contain:

  • job.json

  • events.bson

  • gridfs_data

  • .cs files

  • .mrc files

  • job.log

  • slurm output

Example:

/mnt/xxxxx/CS-fabio-projects-2023-1/J5297/

The job metadata is valid:

uid: J5297
project_uid: P6
workspace_uids: ["W50"]
created_at: 2026-06-25
dumped_at: 2026-06-25

So the job itself appears intact on disk.

Project metadata

The project.json contains:

project_stats.updated_at:
2026-07-07

workspace_count:
21

job_count:
2303

However, it also contains:

"autodump_failed": true

with an error beginning on June 2, 2026:

CSModelException:
Could not update mongo Job...

This makes us suspect that project autodumping began failing around June 2, well before the login node crash.

Current behavior

  • Project P6 attaches successfully.

  • Older jobs are visible.

  • Many June/July jobs and workspaces are missing from the GUI.

  • The corresponding job directories still exist on disk.

  • New jobs submitted after recovery work normally.

Questions

  1. Is there a supported way to rebuild MongoDB metadata from the existing project directory and job.json files?

  2. Could a project with autodump_failed=true have an incomplete project dump even though the individual job directories remain intact?

  3. Is there a recommended procedure to repair or reattach a partially imported project without recreating the entire CryoSPARC database?

  4. Are there any utilities (supported or experimental) that can reconstruct missing jobs/workspaces from the existing project directory?

We have preserved the project directory and recovery logs and are happy to provide additional information if needed.

Thank you very much for any suggestions or guidance.

Project P6 appears in the GUI after recovery, and some jobs are visible. However, attempting to clone any job returns:


Unable to clone P6 J2907:
Project import failed

This suggests the project itself is still marked as having failed import, even though it is attached. Is there a supported way to complete or retry the project import after recovery, or to rebuild the project metadata from the existing project.json and job.json files?

We have verified that the missing jobs still exist on disk. Each job directory contains a valid job.json, events.bson, output .cs files, .mrc files, etc. The project, however, remains in a “Project import failed” state, and jobs cannot be cloned or exported.

Is there a supported utility or internal procedure to rebuild the MongoDB job metadata from the existing job.json files, or otherwise import individual jobs into a new project without reprocessing the data?

Does this mean users could create jobs in P6, but could not clone jobs

Other users can submit jobs in their projects, but not this user with project P6

In addition, export doesn’t work for the jobs in P6

Is it possible to modify the mongo database to mark P6 with a state opposite of “Project import failed“? Any alternative such that at least get some jobs in P6 to be able to be exported?

3 posts were split to a new topic: Recommendations for re-importing a project?

Thank you all for your help!

I was able to delete project P6, since Delete was the only available option in our case; all of the other options were greyed out. I then successfully imported/attached the old P6 project as P73 after repairing the workspaces.json file. Specifically, I manually added entries for the missing workspaces based on the example provided here:

https://discuss.cryosparc.com/t/attach-a-project-without-workspace-json/16392/2

I also noticed that project.json contained an autodump_errors entry showing the following error:

CSModelException: Could not update mongo Job with id 699f2283e4805d7ea031da22 in collection jobs.

Update query: {'$set': {'updated_at': datetime.datetime(2026, 6, 2, 18, 15, 31, 604255, tzinfo=datetime.timezone.utc), 'dumped_at': datetime.datetime(2026, 6, 2, 18, 15, 31, 471804, tzinfo=datetime.timezone.utc), 'last_dumped_version': 'v5.0.6', 'autodump': False, 'resources_allocated.target.tpl_vars': ['ram_gb', 'job_uid', 'ram_gb_multiplier', 'job_creator', 'project_dir_abs', 'job_log_path_abs', 'job_dir_abs', 'cryosparc_username', 'worker_bin_path', 'cluster_job_id', 'run_cmd', 'num_cpu', 'project_uid', 'run_args', 'command', 'num_gpu'], 'last_updated': datetime.datetime(2026, 6, 2, 18, 15, 31, 604255, tzinfo=datetime.timezone.utc), 'last_exported': datetime.datetime(2026, 6, 2, 18, 15, 31, 471804, tzinfo=datetime.timezone.utc), 'output_results': [{'uid': 'J4267-R0', 'type': 'particle.alignments3D_multi', 'name': 'alignments3D_multi', 'group_name': 'particles_all_classes', 'title': 'Particle alignments3D multi', 'description': 'Particle alignments3D multi', 'min_fields': [('num_classes', 'u4'), ('split', 'u4'), ('shift', '({K},2)f4'), ('pose', '({K},3)f4'), ('psize_A', 'f4'), ('error', '({K},)f4'), ('error_min', '({K},)f4'), ('resid_pow', '({K},)f4'), ('slice_pow', '({K},)f4'), ('image_pow', '({K},)f4'), ('cross_cor', '({K},)f4'), ('alpha', '({K},)f4'), ('alpha_min', '({K},)f4'), ('weight', '({K},)f4'), ('pose_ess', '({K},)f4'), ('shift_ess', '({K},)f4'), ('class_posterior', '({K},)f4'), ('class', '({K},)u4'), ('class_ess', 'f4')], 'versions': [178], 'metafiles': ['J4267/J4267_00178_particles.cs'], 'num_items': [172979], 'passthrough': False}, ...}}

I inspected the J4267 job directory and confirmed that it appears to be corrupted, with several expected output files missing.

I therefore edited job_manifest.json to add the missing jobs while excluding J4267.

After these changes, the project import completed successfully and the project was assigned the new ID P73. During the import process, however, many jobs were reported as failed, particularly jobs that had been run in June and early July.

P73 still does not display all of the jobs and workspaces that were previously visible in P6 when the CryoSPARC GUI was functioning normally.

I discovered that some of the missing jobs can still be accessed directly in P73, even though they do not appear in the user interface because their associated workspaces are missing. For example, J5639 can be accessed using the following URL:

http://xxx.dbi.udel.edu:61000/#job(P73-J5639)

The job appears to work correctly. I was able to export a Result Group from P73-J5639 and then import the volume Result Group in a new project.

The remaining questions are:

  1. Is there a way to reconstruct workspaces.json so that the missing workspaces and their associated jobs can appear in the CryoSPARC user interface?

  2. Since project.json still contains the autodump_errors entry related to J4267, should anything be done to correct or remove that entry safely?

Thanks for the update.

This is unexpected in CryoSPARC v5.0.6. Is there any chance that the option shown was Delete Project from Database?

Please can you post the output of the command

grep -n -A 10 -B 5 autodump_errors /mnt/xxxxx/CS-fabio-projects-2023-1/project.json

[edited 2026-07-20: corrected grep command]

I believe the option that was executed was “Delete Project from Database,” which was the only available action.

Note: The timestamp of the autodump_errors entry recorded in project.json coincides with our recent upgrade from CryoSPARC v4 to v5. This suggests that the issue with project.json occurred during the upgrade, even though no apparent error was reported during the process.

The user of project P6 was able to run hundreds of jobs and create several workspaces throughout June and early July without noticing anything unusual. However, both project.json and workspaces.json had not been updated since June 2, around the time the autodump_errors occurred. This suggests that the metadata stopped being written at that point, while the project itself continued to function normally from the user’s perspective until the recent system failure.

Here’s the output for the command: grep -n -A 10 -B 5 autodump_errors /mnt/xxxxx/CS-fabio-projects-2023-1/project.json

135- “last_detached_version”: null,

136- “is_cleanup_in_progress”: false,

137- “tags”: [],

138- “starred_by”: [],

139- “autodump_failed”: true,

140: “autodump_errors”: [

141- “CSModelException: Could not update mongo Job with id 699f2283e4805d7ea031da22 in collection jobs.\nUpdate query: {‘$set’: {‘updated_at’: datetime.datetime(2026, 6, 2, 18, 15, 31, 604255, tzinfo=datetime.timezone.utc), ‘dumped_at’: datetime.datetime(2026, 6, 2, 18, 15, 31, 471804, tzinfo=datetime.timezone.utc), ‘last_dumped_version’: ‘v5.0.6’, ‘autodump’: False, ‘resources_allocated.target.tpl_vars’: [‘ram_gb’, ‘job_uid’, ‘ram_gb_multiplier’, ‘job_creator’, ‘project_dir_abs’, ‘job_log_path_abs’, ‘job_dir_abs’, ‘cryosparc_username’, ‘worker_bin_path’, ‘cluster_job_id’, ‘run_cmd’, ‘num_cpu’, ‘project_uid’, ‘run_args’, ‘command’, ‘num_gpu’], ‘last_updated’: datetime.datetime(2026, 6, 2, 18, 15, 31, 604255, tzinfo=datetime.timezone.utc), ‘last_exported’: datetime.datetime(2026, 6, 2, 18, 15, 31, 471804, tzinfo=datetime.timezone.utc), ‘output_results’: [{‘uid’: ‘J4267-R0’, ‘type’: ‘particle.alignments3D_multi’, ‘name’: ‘alignments3D_multi’, ‘group_name’: ‘particles_all_classes’, ‘title’: ‘Particle alignments3D multi’, ‘description’: ‘Particle alignments3D multi’, ‘min_fields’: [(‘num_classes’, ‘u4’), (‘split’, ‘u4’), (‘shift’, ‘({K},2)f4’), (‘pose’, ‘({K},3)f4’), (‘psize_A’, ‘f4’), (‘error’, ‘({K},)f4’), (‘error_min’, ‘({K},)f4’), (‘resid_pow’, ‘({K},)f4’), (‘slice_pow’, ‘({K},)f4’), (‘image_pow’, ‘({K},)f4’), (‘cross_cor’, ‘({K},)f4’), (‘alpha’, ‘({K},)f4’), (‘alpha_min’, ‘({K},)f4’), (‘weight’, ‘({K},)f4’), (‘pose_ess’, ‘({K},)f4’), (‘shift_ess’, ‘({K},)f4’), (‘class_posterior’, ‘({K},)f4’), (‘class’, ‘({K},)u4’), (‘class_ess’, ‘f4’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_00178_particles.cs’], ‘num_items’: [172979], ‘passthrough’: False}, {‘uid’: ‘J4267-R1’, ‘type’: ‘particle.blob’, ‘name’: ‘blob’, ‘group_name’: ‘particles_all_classes’, ‘title’: ‘Particle blob’, ‘description’: ‘Particle blob’, ‘min_fields’: [(‘path’, ‘O’), (‘idx’, ‘u4’), (‘shape’, ‘2u4’), (‘psize_A’, ‘f4’), (‘sign’, ‘f4’), (‘import_sig’, ‘u8’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_all_classes.cs’], ‘num_items’: [172979], ‘passthrough’: True}, {‘uid’: ‘J4267-R2’, ‘type’: ‘particle.ctf’, ‘name’: ‘ctf’, ‘group_name’: ‘particles_all_classes’, ‘title’: ‘Particle ctf’, ‘description’: ‘Particle ctf’, ‘min_fields’: [(‘type’, ‘O’), (‘exp_group_id’, ‘u4’), (‘accel_kv’, ‘f4’), (‘cs_mm’, ‘f4’), (‘amp_contrast’, ‘f4’), (‘df1_A’, ‘f4’), (‘df2_A’, ‘f4’), (‘df_angle_rad’, ‘f4’), (‘phase_shift_rad’, ‘f4’), (‘scale’, ‘f4’), (‘scale_const’, ‘f4’), (‘shift_A’, ‘2f4’), (‘tilt_A’, ‘2f4’), (‘trefoil_A’, ‘2f4’), (‘tetra_A’, ‘4f4’), (‘anisomag’, ‘4f4’), (‘bfactor’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_all_classes.cs’], ‘num_items’: [172979], ‘passthrough’: True}, {‘uid’: ‘J4267-R3’, ‘type’: ‘particle.alignments3D’, ‘name’: ‘alignments3D’, ‘group_name’: ‘particles_all_classes’, ‘title’: ‘Particle alignments3D’, ‘description’: ‘Particle alignments3D’, ‘min_fields’: [(‘split’, ‘u4’), (‘shift’, ‘2f4’), (‘pose’, ‘3f4’), (‘psize_A’, ‘f4’), (‘error’, ‘f4’), (‘error_min’, ‘f4’), (‘resid_pow’, ‘f4’), (‘slice_pow’, ‘f4’), (‘image_pow’, ‘f4’), (‘cross_cor’, ‘f4’), (‘alpha’, ‘f4’), (‘alpha_min’, ‘f4’), (‘weight’, ‘f4’), (‘pose_ess’, ‘f4’), (‘shift_ess’, ‘f4’), (‘class_posterior’, ‘f4’), (‘class’, ‘u4’), (‘class_ess’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_all_classes.cs’], ‘num_items’: [172979], ‘passthrough’: True}, {‘uid’: ‘J4267-R4’, ‘type’: ‘particle.location’, ‘name’: ‘location’, ‘group_name’: ‘particles_all_classes’, ‘title’: ‘Particle location’, ‘description’: ‘Particle location’, ‘min_fields’: [(‘micrograph_uid’, ‘u8’), (‘exp_group_id’, ‘u4’), (‘micrograph_path’, ‘O’), (‘micrograph_shape’, ‘2u4’), (‘micrograph_psize_A’, ‘f4’), (‘center_x_frac’, ‘f4’), (‘center_y_frac’, ‘f4’), (‘min_dist_A’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_all_classes.cs’], ‘num_items’: [172979], ‘passthrough’: True}, {‘uid’: ‘J4267-R5’, ‘type’: ‘particle.pick_stats’, ‘name’: ‘pick_stats’, ‘group_name’: ‘particles_all_classes’, ‘title’: ‘Particle pick stats’, ‘description’: ‘Particle pick stats’, ‘min_fields’: [(‘ncc_score’, ‘f4’), (‘power’, ‘f4’), (‘template_idx’, ‘u4’), (‘angle_rad’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_all_classes.cs’], ‘num_items’: [172979], ‘passthrough’: True}, {‘uid’: ‘J4267-R6’, ‘type’: ‘particle.alignments2D’, ‘name’: ‘alignments2D’, ‘group_name’: ‘particles_all_classes’, ‘title’: ‘Particle alignments2D’, ‘description’: ‘Particle alignments2D’, ‘min_fields’: [(‘split’, ‘u4’), (‘shift’, ‘2f4’), (‘pose’, ‘f4’), (‘psize_A’, ‘f4’), (‘error’, ‘f4’), (‘error_min’, ‘f4’), (‘resid_pow’, ‘f4’), (‘slice_pow’, ‘f4’), (‘image_pow’, ‘f4’), (‘cross_cor’, ‘f4’), (‘alpha’, ‘f4’), (‘alpha_min’, ‘f4’), (‘weight’, ‘f4’), (‘pose_ess’, ‘f4’), (‘shift_ess’, ‘f4’), (‘class_posterior’, ‘f4’), (‘class’, ‘u4’), (‘class_ess’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_all_classes.cs’], ‘num_items’: [172979], ‘passthrough’: True}, {‘uid’: ‘J4267-R7’, ‘type’: ‘volume_multi.blob’, ‘name’: ‘map’, ‘group_name’: ‘volumes_all_classes’, ‘title’: ‘Volume_multi map’, ‘description’: ‘Volume_multi map’, ‘min_fields’: [(‘path’, ‘O’), (‘shape’, ‘3u4’), (‘psize_A’, ‘f4’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_00178_volume_series.cs’], ‘num_items’: [2], ‘passthrough’: False}, {‘uid’: ‘J4267-R8’, ‘type’: ‘volume_multi.classification_info’, ‘name’: ‘classification_info’, ‘group_name’: ‘volumes_all_classes’, ‘title’: ‘Volume_multi classification info’, ‘description’: ‘Volume_multi classification info’, ‘min_fields’: [(‘class’, ‘u4’), (‘num_particles’, ‘u4’), (‘effective_size’, ‘f4’), (‘average_class_ess’, ‘f4’), (‘type’, ‘O’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_00178_volume_series.cs’], ‘num_items’: [2], ‘passthrough’: False}, {‘uid’: ‘J4267-R9’, ‘type’: ‘volume_multi.fsc_info’, ‘name’: ‘fsc_info_nomask’, ‘group_name’: ‘volumes_all_classes’, ‘title’: ‘Volume_multi fsc info nomask’, ‘description’: ‘Volume_multi fsc info nomask’, ‘min_fields’: [(‘type’, ‘O’), (‘fsc’, ‘{N_T}f4’), (‘res_05_A’, ‘f4’), (‘res_0143_A’, ‘f4’), (‘psize_A’, ‘f4’), (‘box_size’, ‘u4’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_00178_volume_series.cs’], ‘num_items’: [2], ‘passthrough’: False}, {‘uid’: ‘J4267-R10’, ‘type’: ‘volume_multi.fsc_info’, ‘name’: ‘fsc_info_mask’, ‘group_name’: ‘volumes_all_classes’, ‘title’: ‘Volume_multi fsc info mask’, ‘description’: ‘Volume_multi fsc info mask’, ‘min_fields’: [(‘type’, ‘O’), (‘fsc’, ‘{N_T}f4’), (‘res_05_A’, ‘f4’), (‘res_0143_A’, ‘f4’), (‘psize_A’, ‘f4’), (‘box_size’, ‘u4’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_00178_volume_series.cs’], ‘num_items’: [2], ‘passthrough’: False}, {‘uid’: ‘J4267-R11’, ‘type’: ‘volume_multi.series’, ‘name’: ‘series’, ‘group_name’: ‘volumes_all_classes’, ‘title’: ‘Volume_multi series’, ‘description’: ‘Volume_multi series’, ‘min_fields’: [(‘path’, ‘O’), (‘count’, ‘u4’), (‘shape’, ‘3u4’), (‘psize_A’, ‘f4’), (‘type’, ‘O’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_00178_volume_series.cs’], ‘num_items’: [2], ‘passthrough’: False}, {‘uid’: ‘J4267-R12’, ‘type’: ‘volume.blob’, ‘name’: ‘map’, ‘group_name’: ‘volume_consensus’, ‘title’: ‘Volume map’, ‘description’: ‘Volume map’, ‘min_fields’: [(‘path’, ‘O’), (‘shape’, ‘3u4’), (‘psize_A’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_volume_map_consensus.cs’], ‘num_items’: [1], ‘passthrough’: False}, {‘uid’: ‘J4267-R13’, ‘type’: ‘volume.blob’, ‘name’: ‘mask’, ‘group_name’: ‘mask_solvent’, ‘title’: ‘Mask mask’, ‘description’: ‘Mask mask’, ‘min_fields’: [(‘path’, ‘O’), (‘shape’, ‘3u4’), (‘psize_A’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267__mask_solvent.cs’], ‘num_items’: [1], ‘passthrough’: False}, {‘uid’: ‘J4267-R14’, ‘type’: ‘particle.alignments3D’, ‘name’: ‘alignments3D’, ‘group_name’: ‘particles_class_0’, ‘title’: ‘Particle alignments3D’, ‘description’: ‘Particle alignments3D’, ‘min_fields’: [(‘split’, ‘u4’), (‘shift’, ‘2f4’), (‘pose’, ‘3f4’), (‘psize_A’, ‘f4’), (‘error’, ‘f4’), (‘error_min’, ‘f4’), (‘resid_pow’, ‘f4’), (‘slice_pow’, ‘f4’), (‘image_pow’, ‘f4’), (‘cross_cor’, ‘f4’), (‘alpha’, ‘f4’), (‘alpha_min’, ‘f4’), (‘weight’, ‘f4’), (‘pose_ess’, ‘f4’), (‘shift_ess’, ‘f4’), (‘class_posterior’, ‘f4’), (‘class’, ‘u4’), (‘class_ess’, ‘f4’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_class_00_00178_particles.cs’], ‘num_items’: [88274], ‘passthrough’: False}, {‘uid’: ‘J4267-R15’, ‘type’: ‘particle.blob’, ‘name’: ‘blob’, ‘group_name’: ‘particles_class_0’, ‘title’: ‘Particle blob’, ‘description’: ‘Particle blob’, ‘min_fields’: [(‘path’, ‘O’), (‘idx’, ‘u4’), (‘shape’, ‘2u4’), (‘psize_A’, ‘f4’), (‘sign’, ‘f4’), (‘import_sig’, ‘u8’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_0.cs’], ‘num_items’: [88274], ‘passthrough’: True}, {‘uid’: ‘J4267-R16’, ‘type’: ‘particle.ctf’, ‘name’: ‘ctf’, ‘group_name’: ‘particles_class_0’, ‘title’: ‘Particle ctf’, ‘description’: ‘Particle ctf’, ‘min_fields’: [(‘type’, ‘O’), (‘exp_group_id’, ‘u4’), (‘accel_kv’, ‘f4’), (‘cs_mm’, ‘f4’), (‘amp_contrast’, ‘f4’), (‘df1_A’, ‘f4’), (‘df2_A’, ‘f4’), (‘df_angle_rad’, ‘f4’), (‘phase_shift_rad’, ‘f4’), (‘scale’, ‘f4’), (‘scale_const’, ‘f4’), (‘shift_A’, ‘2f4’), (‘tilt_A’, ‘2f4’), (‘trefoil_A’, ‘2f4’), (‘tetra_A’, ‘4f4’), (‘anisomag’, ‘4f4’), (‘bfactor’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_0.cs’], ‘num_items’: [88274], ‘passthrough’: True}, {‘uid’: ‘J4267-R17’, ‘type’: ‘particle.location’, ‘name’: ‘location’, ‘group_name’: ‘particles_class_0’, ‘title’: ‘Particle location’, ‘description’: ‘Particle location’, ‘min_fields’: [(‘micrograph_uid’, ‘u8’), (‘exp_group_id’, ‘u4’), (‘micrograph_path’, ‘O’), (‘micrograph_shape’, ‘2u4’), (‘micrograph_psize_A’, ‘f4’), (‘center_x_frac’, ‘f4’), (‘center_y_frac’, ‘f4’), (‘min_dist_A’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_0.cs’], ‘num_items’: [88274], ‘passthrough’: True}, {‘uid’: ‘J4267-R18’, ‘type’: ‘particle.pick_stats’, ‘name’: ‘pick_stats’, ‘group_name’: ‘particles_class_0’, ‘title’: ‘Particle pick stats’, ‘description’: ‘Particle pick stats’, ‘min_fields’: [(‘ncc_score’, ‘f4’), (‘power’, ‘f4’), (‘template_idx’, ‘u4’), (‘angle_rad’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_0.cs’], ‘num_items’: [88274], ‘passthrough’: True}, {‘uid’: ‘J4267-R19’, ‘type’: ‘particle.alignments2D’, ‘name’: ‘alignments2D’, ‘group_name’: ‘particles_class_0’, ‘title’: ‘Particle alignments2D’, ‘description’: ‘Particle alignments2D’, ‘min_fields’: [(‘split’, ‘u4’), (‘shift’, ‘2f4’), (‘pose’, ‘f4’), (‘psize_A’, ‘f4’), (‘error’, ‘f4’), (‘error_min’, ‘f4’), (‘resid_pow’, ‘f4’), (‘slice_pow’, ‘f4’), (‘image_pow’, ‘f4’), (‘cross_cor’, ‘f4’), (‘alpha’, ‘f4’), (‘alpha_min’, ‘f4’), (‘weight’, ‘f4’), (‘pose_ess’, ‘f4’), (‘shift_ess’, ‘f4’), (‘class_posterior’, ‘f4’), (‘class’, ‘u4’), (‘class_ess’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_0.cs’], ‘num_items’: [88274], ‘passthrough’: True}, {‘uid’: ‘J4267-R20’, ‘type’: ‘volume.blob’, ‘name’: ‘map’, ‘group_name’: ‘volume_class_0’, ‘title’: ‘Volume map’, ‘description’: ‘Volume map’, ‘min_fields’: [(‘path’, ‘O’), (‘shape’, ‘3u4’), (‘psize_A’, ‘f4’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_class_00_00178_volume.cs’], ‘num_items’: [1], ‘passthrough’: False}, {‘uid’: ‘J4267-R21’, ‘type’: ‘particle.alignments3D’, ‘name’: ‘alignments3D’, ‘group_name’: ‘particles_class_1’, ‘title’: ‘Particle alignments3D’, ‘description’: ‘Particle alignments3D’, ‘min_fields’: [(‘split’, ‘u4’), (‘shift’, ‘2f4’), (‘pose’, ‘3f4’), (‘psize_A’, ‘f4’), (‘error’, ‘f4’), (‘error_min’, ‘f4’), (‘resid_pow’, ‘f4’), (‘slice_pow’, ‘f4’), (‘image_pow’, ‘f4’), (‘cross_cor’, ‘f4’), (‘alpha’, ‘f4’), (‘alpha_min’, ‘f4’), (‘weight’, ‘f4’), (‘pose_ess’, ‘f4’), (‘shift_ess’, ‘f4’), (‘class_posterior’, ‘f4’), (‘class’, ‘u4’), (‘class_ess’, ‘f4’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_class_01_00178_particles.cs’], ‘num_items’: [84705], ‘passthrough’: False}, {‘uid’: ‘J4267-R22’, ‘type’: ‘particle.blob’, ‘name’: ‘blob’, ‘group_name’: ‘particles_class_1’, ‘title’: ‘Particle blob’, ‘description’: ‘Particle blob’, ‘min_fields’: [(‘path’, ‘O’), (‘idx’, ‘u4’), (‘shape’, ‘2u4’), (‘psize_A’, ‘f4’), (‘sign’, ‘f4’), (‘import_sig’, ‘u8’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_1.cs’], ‘num_items’: [84705], ‘passthrough’: True}, {‘uid’: ‘J4267-R23’, ‘type’: ‘particle.ctf’, ‘name’: ‘ctf’, ‘group_name’: ‘particles_class_1’, ‘title’: ‘Particle ctf’, ‘description’: ‘Particle ctf’, ‘min_fields’: [(‘type’, ‘O’), (‘exp_group_id’, ‘u4’), (‘accel_kv’, ‘f4’), (‘cs_mm’, ‘f4’), (‘amp_contrast’, ‘f4’), (‘df1_A’, ‘f4’), (‘df2_A’, ‘f4’), (‘df_angle_rad’, ‘f4’), (‘phase_shift_rad’, ‘f4’), (‘scale’, ‘f4’), (‘scale_const’, ‘f4’), (‘shift_A’, ‘2f4’), (‘tilt_A’, ‘2f4’), (‘trefoil_A’, ‘2f4’), (‘tetra_A’, ‘4f4’), (‘anisomag’, ‘4f4’), (‘bfactor’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_1.cs’], ‘num_items’: [84705], ‘passthrough’: True}, {‘uid’: ‘J4267-R24’, ‘type’: ‘particle.location’, ‘name’: ‘location’, ‘group_name’: ‘particles_class_1’, ‘title’: ‘Particle location’, ‘description’: ‘Particle location’, ‘min_fields’: [(‘micrograph_uid’, ‘u8’), (‘exp_group_id’, ‘u4’), (‘micrograph_path’, ‘O’), (‘micrograph_shape’, ‘2u4’), (‘micrograph_psize_A’, ‘f4’), (‘center_x_frac’, ‘f4’), (‘center_y_frac’, ‘f4’), (‘min_dist_A’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_1.cs’], ‘num_items’: [84705], ‘passthrough’: True}, {‘uid’: ‘J4267-R25’, ‘type’: ‘particle.pick_stats’, ‘name’: ‘pick_stats’, ‘group_name’: ‘particles_class_1’, ‘title’: ‘Particle pick stats’, ‘description’: ‘Particle pick stats’, ‘min_fields’: [(‘ncc_score’, ‘f4’), (‘power’, ‘f4’), (‘template_idx’, ‘u4’), (‘angle_rad’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_1.cs’], ‘num_items’: [84705], ‘passthrough’: True}, {‘uid’: ‘J4267-R26’, ‘type’: ‘particle.alignments2D’, ‘name’: ‘alignments2D’, ‘group_name’: ‘particles_class_1’, ‘title’: ‘Particle alignments2D’, ‘description’: ‘Particle alignments2D’, ‘min_fields’: [(‘split’, ‘u4’), (‘shift’, ‘2f4’), (‘pose’, ‘f4’), (‘psize_A’, ‘f4’), (‘error’, ‘f4’), (‘error_min’, ‘f4’), (‘resid_pow’, ‘f4’), (‘slice_pow’, ‘f4’), (‘image_pow’, ‘f4’), (‘cross_cor’, ‘f4’), (‘alpha’, ‘f4’), (‘alpha_min’, ‘f4’), (‘weight’, ‘f4’), (‘pose_ess’, ‘f4’), (‘shift_ess’, ‘f4’), (‘class_posterior’, ‘f4’), (‘class’, ‘u4’), (‘class_ess’, ‘f4’)], ‘versions’: [0], ‘metafiles’: [‘J4267/J4267_passthrough_particles_class_1.cs’], ‘num_items’: [84705], ‘passthrough’: True}, {‘uid’: ‘J4267-R27’, ‘type’: ‘volume.blob’, ‘name’: ‘map’, ‘group_name’: ‘volume_class_1’, ‘title’: ‘Volume map’, ‘description’: ‘Volume map’, ‘min_fields’: [(‘path’, ‘O’), (‘shape’, ‘3u4’), (‘psize_A’, ‘f4’)], ‘versions’: [178], ‘metafiles’: [‘J4267/J4267_class_01_00178_volume.cs’], ‘num_items’: [1], ‘passthrough’: False}]}}”

142- ],

143- “workflows”: null,

144- “uid_num”: 73

145-}

The autodump_errors item inside the project.json file should not, in and by itself, affect the project import. The (yet) unidentified cause of the autodump failure, however, if it persists, may interfere with the import.
Please can you send us compressed copies of the database.log[.?], scheduler.log[.?] and api.log[.?] files that cover the period on June 2 where the problem with job J4276 occurred? The log files can be found in the cryosparc_master/run/ directory. If a log rotated after June 2, the relevant log file may end with .log.1, .log.2, etc.
I will let you know our email address in a direct message.

Thanks @UDwangq for sending us the logs. The logs indicate a rare combination of events that triggered a bug in CryoSPARC. In CryoSPARC v5.0.6, one can resume autodumps for an attached project after an autodump failure by running the command (for a hypothetical project with uid P9999)

cryosparcm cli "api.projects.reset_autodump('P9999')"

@UDwangq We just released CryoSPARC v5.0.7, including a fix related to autodump:
In CryoSPARC versions before v5.0.7, automatic, continuous export (autodump) may be disrupted for a project after an autodump error occurs. After an autodump error occurs in v5.0.7, autodump will be reattempted in intervals, which would re-enable autodump for the project if a temporary impediment, such as a network disruption, is resolved.

@UDwangq Do you still need help recovering data from the project that you attached as project P73? If so, please can you post any changes to or progress with that project since your latest post.

Jobs that were imported successfully but whose associated workspace does not exist for some reason are included in the display if one selects the View <some number> Jobs option from the project card’s upper-right dropdown menu.