Events captured by the Bridge as part of the snapshot's history (CURRENT)
| Event | Data* | Who/What initiates it?Initiated By |
|---|---|---|
| Snapshot Complete | alternateIds: ['id1', 'id2', 'id3',...] TODO: add snapshot-action: SNAPSHOT_COMPLETE method | NodeIntake Service |
| Request Restore Snapshot | initiating-user: <user email> restore-action: RESTORE_REQUESTED | Bridge User |
| Restore Initiated | restore-id: <restore-id> restore-action: RESTORE_INITIATED user-email: <request initiating user email> | Bridge Admin |
| Restore Completed | restore-id: <restore-id> restore-action: RESTORE_COMPLETED expiration-date: yyyy-MM-dd | Bridge System |
| Restore Expired | restore-id: <restore-id> restore-action: RESTORE_EXPIRED | Bridge System |
*All events have a date stamp associated with them.
Additionally, nodes can append node specific events to the snapshot history at any time via the /snapshot/{snapshot-id}/history REST call.
Events captured by the Bridge Intake Service (CURRENT)
The failure of a DPN transfer isn't captured, but could be. Also, the event name is hidden from the user so these look quite cryptic in the displayed history.
Event | Data | Initiated By |
|---|---|---|
| Bagging Completed |
| Intake |
| Transfer to DPN Node |
| Intake |
Actions we should be capturing in snapshot history (TO DO)
| Event | Data* | Who/What initiates it?Initiated By |
|---|---|---|
| Snapshot Initiated |
| Bridge |
| Snapshot Transfer to Chronopolis Complete |
| Bridge |
| Bagging Completed |
| Intake Service |
| Snapshot Replication to DPN Nodes |
| Intake Service |
| Snapshot Complete |
| Call to complete snapshot made by Intake Service Event captured by Bridge |
| Snapshot Bit Integrity Check Complete |
| ACE webhook? |
...