Technical_Overview

Technical Overview

Event Types

The event types your triggers can register to be notified of are generally respect the following form Shotgun_[entity_type]_[New|Change|Retirement|Revival]. Here are a few examples of this pattern:

Shotgun_Note_New
Shotgun_Shot_New
Shotgun_Task_Change
Shotgun_CustomEntity06_Change
Shotgun_Playlist_Retirement
Shotgun_Playlist_Revival

Some notable departures from this pattern are used for events that aren't related to entity record activity but rather key points in application behavior.

CRS_PlaylistShare_Create
CRS_PlaylistShare_Revoke 
SG_RV_Session_Validate_Success
Shotgun_Attachment_View
Shotgun_Big_Query
Shotgun_NotesApp_Summary_Email
Shotgun_User_FailedLogin
Shotgun_User_Login
Shotgun_User_Logout
Toolkit_App_Startup
Toolkit_Desktop_ProjectLaunch
Toolkit_Desktop_AppLaunch
Toolkit_Folders_Create
Toolkit_Folders_Delete    

This list is not exhaustive but is a good place to start. If you wish to know more about the activity and event types on your Shotgun site, please consult a page of EventLogEntries where you can filter and search through like any other grid page of any other entity type.

Plugin Processing Order

Each event is always processed in the same predictable order so that if any plugins or callbacks are co-dependant, you can safely organize their processing.

The configuration file specifies a paths config that contains one or multiple plugin locations. The earlier the location in the list the sooner the contained plugins will be processed.

Each plugin within a plugin path is then processed in ascending alphabetical order.

Note: Internally the filenames are put in a list and sorted.

Finally, each callback registered by a plugin is called in registration order. First registered, first run.

We suggested keeping any functionality that needs to share state somehow in the same plugin as one or multiple callbacks.

Sharing state

Many options exist for multiple callbacks that need to share state.

• Global variables. Ick. Please don't do this.
• An imported module that holds the state information. Ick, but a bit better than simple globals.
• A mutable passed in the args argument when calling Registrar.registerCallback. A state object of your design or something as simple as a dict. Preferred.
• Implement callbacks such as __call__ on object instances and provide some shared state object at callback object initialization. Most powerful yet most convoluted method. May be redundant compared to the args argument method above.

Error Messages

Here is a brief overview of some error and warning messages that may appear in your logs, depending on your configured logging level.

Timeout elapsed on backlog event ID

Each event that occurs in Shotgun (field update, entity creation, entity retirement, etc.) has a unique ID number for its event log entry. Sometimes there are gaps in the ID number sequence. These gaps can occur for many reasons, one of them being a large database transaction that has not yet been completed.

Every time there is a gap in the event log sequence the "missing" event IDs are put into a backlog for later processing. This allows for the event daemon to process the events from a long database transaction once it has finished.

Sometimes the gap in the event log sequence will never be filled in, such as with a failed transaction or reverted page setting modifications. In this case the event log entry ID number that was put in the backlog will eventually hit a timeout (5 minutes) and the system will stop waiting for this event to appear. At this time you will see a "Timeout elapsed on backlog event id #####" message. This message can also appear as "Event ###### never happened - ignoring" the first time en event is seen and it is already deemed to old to be put in the backlog in the first place.