RNA-seq Sample-sheet Preflight
Pricing
$0.05 / useful rna-seq metadata receipt
RNA-seq Sample-sheet Preflight
Experimental checks on authorized inline RNA-seq CSV: row findings, exact sample-group conflicts and explicit coverage. Finite profile informed by nf-core/rnaseq 3.27.0; no FASTQ access, native validator execution or pipeline-readiness certification.
Pricing
$0.05 / useful rna-seq metadata receipt
Rating
0.0
(0)
Developer
L3Digital
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
17 days ago
Last modified
Categories
Share
Find metadata problems and conflicting rows for the same exact sample ID before reviewing an RNA-seq sample sheet for a run. Supply a small authorized inline CSV; one bounded report localizes row findings and sample-group conflicts with explicit coverage, without opening FASTQ files or running a pipeline.
This experimental profile is informed by nf-core/rnaseq 3.27.0 and its nf-schema 2.7.2 pin. It is not their native validator, an official endorsement, a complete compatibility check or a pipeline-readiness certificate. Existing nf-schema, workflow and local validation tools are strong substitutes; customer demand and savings from this managed call remain unvalidated.
Input
Use the always-uncharged synthetic demo:
{"demo": true}
For real metadata, provide these exact keys:
In the Console form, turn off Synthetic demo before entering real metadata.
{"processingPermission": true,"profile": "rnaseq-3.27.0-metadata-v1","csvText": "sample,fastq_1,fastq_2,strandedness\n001,lane1_R1.fastq.gz,lane1_R2.fastq.gz,auto\n"}
demo and processingPermission are actual booleans, default false. Real input
requires permission true and the exact profile. Demo requires profile and CSV
to be absent, even if empty/null, with permission false or absent. Unknown
keys, nulls, coercion, mixed modes, NUL and malformed Unicode are refused.
Only authorized metadata is accepted. No files, URLs, schemas, shell commands,
credentials or customer code are fetched or executed. Paths are inert strings.
Required headers are sample, fastq_1, fastq_2, strandedness, with optional
seq_platform, seq_center, in any order. Headers must be exact, unique and
unmodified; additional BAM or percent-mapped columns are outside this profile.
All data records must have the header width. Invalid structure refuses the
whole sheet, including any earlier well-formed rows.
Python's strict comma/double-quote CSV parser accepts LF/CRLF and quoted fields. One leading UTF-8 BOM is removed and recorded; identifiers and cell values are never trimmed, normalized, case-folded or numerically converted. Genuinely empty records are skipped, while whitespace-filled records remain records. Record numbers are logical data records starting at one, excluding the header and skipped empty records; quoted newlines do not become additional records. This chosen parser does not certify complete RFC grammar conformance.
Selected checks and group coverage
Empty sample IDs fail sample_required; nonempty IDs with Unicode whitespace
fail sample_whitespace. C0/DEL controls anywhere in a cell fail cell_control,
including quoted newline/tab text. Invalid sample rows remain accounted for,
but are excluded from sample grouping. No ASCII-only or biological-identity
rule is applied. 001, 1, composed/decomposed Unicode and case variants remain
exact distinct identifiers.
The first read is required. Nonempty read filenames must end in case-sensitive
.fq, .fastq, .fq.gz or .fastq.gz, with no whitespace or slash in the
filename portion. Directory spaces can match the selected tagged filename
syntax. The mate can be empty for single-end metadata. Cell controls suppress
additional suffix findings for that cell. Filenames never establish actual
read pairing, read contents or file access. The selected tagged schema allows
uncompressed FASTQ and disallows sample whitespace; guide wording elsewhere
may differ. Native coercions and workflow behavior are unchecked.
Strandedness must be exactly auto, forward, reverse or unstranded.
Nonempty optional platform/center values must contain no Unicode whitespace.
Controls are checked separately. Empty optional values and absent optional
columns contribute the same empty metadata value.
Each eligible exact sample ID forms one group across its records. Groups are
ordered by first occurrence. Five fields are inspected: strandedness, platform,
center, endedness and compression. Valid contributing values produce
consistent or conflict; a relevant row finding in any contributing cell
produces not_checked. Endedness and compression depend on both read cells.
Compression checks both nonempty mates, so mixed compressed/uncompressed paths
within one record can conflict. Each conflict emits one group finding with all
of that group's logical record numbers. Every row and group field has explicit
coverage; excluded rows are never presented as group-checked.
No cross-sample path uniqueness, lane inference, biological replicate, actual strandedness or clinical correctness check is performed.
Full receipt and failures
After successful delivery, REPORT in the default key-value store and the one
full default dataset item contain identical JSON. Use the Output tab's
Complete REPORT JSON link, or retrieve
GET /v2/key-value-stores/{defaultKeyValueStoreId}/records/REPORT with appropriate
Apify authorization. Dataset table views summarize the receipt; the full JSON
contains row checks, findings, exact sample IDs, groups and coverage counters.
Raw paths and arbitrary exception strings are omitted. This is not anonymization.
Statuses are complete, refused and failed. A complete receipt means all
selected applicable checks finished, including explicitly excluded and
not_checked coverage. Findings yield review_findings; a receipt without
findings yields no_findings_in_completed_checks with its unchecked scope.
Refusals/failures yield not_inspected and a fixed reason. None of these outcomes
means valid, conformant, safe, ready or successful pipeline execution.
Recover and retain this run's evidence
- Use your authorized Apify caller to start asynchronously. Save the returned run
idand a caller-generated request key in your own records before proceeding; retaindefaultKeyValueStoreIdanddefaultDatasetIdfrom the run response. - Check
GET /v2/actor-runs/RUN_IDwith that saved ID (run API). If a wait or retrieval times out, check the same run again. A failed or timed-out run can still have stored output; inspect it before deciding what to do. - Retrieve the authoritative full receipt with
GET /v2/key-value-stores/STORE_ID/records/REPORT, using that run'sdefaultKeyValueStoreIdasSTORE_ID(record API). Its equal dataset item is available atGET /v2/datasets/DATASET_ID/items?format=json, usingdefaultDatasetId(dataset items API). CheckREPORTduring failure recovery even if dataset delivery failed. - Export the full typed JSON, parse it and verify the input binding and decision-required evidence before acting or cleaning up. Keep
catalogVersion,profile,input.sha256, exact sample IDs, row/group findings and coverage. Preserve IDs such as001as strings.completecan include excluded rows andnot_checkedgroup fields; this contract has nopartialstatus.
Do not silently POST again after a failed retrieval. If the initial start response was lost and no run ID is known, reconcile your authorized run history against your recorded request and input before considering a paid restart. A missing response does not prove no run started; this workflow promises no universal start idempotency.
A table or optional dataset field projection can support a limited notification, but it is not the full report. Retain the run/storage IDs, the identity and version/profile fields above, and relevant coverage; retrieve omitted detail from this same run before making a detailed decision.
Selective cleanup
After the run is terminal, no restart is planned and your exported evidence has been parsed and verified, you may remove authorized copies you no longer need. Use your saved exact storage IDs, never a latest-run shortcut or an assumed shared store. See Apify's record deletion and dataset deletion references for platform operations, which were not exercised in this Actor's QA: deleting INPUT leaves REPORT; deleting REPORT does not delete the dataset. Input records, REPORT records, dataset items and external copies are separate. Removing one does not erase logs, exports, saved task input, source files or customer copies, or guarantee provider-wide erasure.
Limits, storage and price
| Bound | Maximum |
|---|---|
| Original UTF-8 CSV | 256 KiB (262,144 bytes) |
| Logical data records / columns | 2,000 / 6 |
| Sample and other metadata cells | 128 characters |
| Each read path cell | 4,096 characters |
| Serialized UTF-8 report | 1 MiB (1,048,576 bytes) |
| Adapter cancellation deadline / recommended platform timeout | 55 / 60 seconds |
| Candidate platform memory | 256 MiB |
If output exceeds its cap, the whole receipt is refused as output_limit;
no partial receipt is charged. Bounds are design choices, not measured maximum
resource or scalability guarantees. No native process, Java or Nextflow is needed.
SDK shutdown cleanup can continue after the 55-second cancellation deadline;
the separately configured platform timeout bounds the hosted run.
The current price is $0.05 per useful report. Useful means real, non-demo, complete
selected metadata checking with at least one parsed row. Metadata conflicts
and excluded-row findings can be useful results. Demo, refused and failed
receipts are uncharged. Equal REPORT and dataset copies precede at most one
eligible report-produced event. Storage, charge or deadline failures fail the
run without application replay; dataset redirects are disabled. SDK/platform
behavior remains outside any exactly-once storage guarantee.
Authorized input and output may persist in normal Apify storage. No automatic deletion, original-input redaction, erasure or nonretention is promised.