You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fastq Manager shouldn't be responsible for listening to events that could be used to import fastq metadata.
However no other service should also be responsible for registering these fastqs.
Instead we have a simple 'fastq-glue' service that performs the following:
Listens to the sequencer run manager event (which ever one says that a samplesheet exists) - this is hopefully before the run finishes
Creates fastq-sets for each library in the samplesheet, and deals with the logic of if it should be added to the existing fastq set for that library or register a new fastq set (handle topup / rerun scenario).
Generates an event saying 'new fastqs registered' which simply prints an instrument run id.
Future glue services will be able to then subscribe to this event and query the fastq manager and decide if they need to unarchive any complementary data, and call the unarchive service, see Add fastq-sync service #871, say new tumor has arrived for a subject that ran multiple months ago. Note that this would run asynchronously. Glue services instead call the fastq-sync service in Add fastq-sync service #871.
Listens to the future bclconvert / ora-compression pipeline that places ora files in the primary directory.
Adds 'readsets' to the fastq objects mentioned above, so now fastq objects have file-information.
Generates an event to say that fastq object readsets have been added to the database for the instrument run id.
This will be the trigger for future glue services to generate 'READY' events.
This will replace the 'clag' services of the stacky stack. No more showers :(
The text was updated successfully, but these errors were encountered:
A few other things that this service could/should provide.
Running sequali stats for new fastq samples.
Calculating the total fileGzSizeInBytes for fastq samples - beneficial for services that need to decompress ora samples prior to running their analyses such as cttsov2
Fastq Manager shouldn't be responsible for listening to events that could be used to import fastq metadata.
However no other service should also be responsible for registering these fastqs.
Instead we have a simple 'fastq-glue' service that performs the following:
Listens to the sequencer run manager event (which ever one says that a samplesheet exists) - this is hopefully before the run finishes
Listens to the future bclconvert / ora-compression pipeline that places ora files in the primary directory.
This will replace the 'clag' services of the stacky stack. No more showers :(
The text was updated successfully, but these errors were encountered: