Row Lifecycle

This page describes where row data exists at each stage of the pipeline, what is transient, what is persisted, and how errors propagate through the system.

Where Rows Exist

Stage-by-Stage Location

Stage	Row Location	Format
File upload	Client memory	Binary file stream
Parse	Client memory	Tabular representation (headers + rows)
Validate	Client memory	Rows with validation status
Mask	Client memory	Internal binary format
Transform	Client memory	Internal binary format
Profile	Client memory	Rows
Export	Client memory → File blob	CSV/XLSX binary
Sync	Client memory → HTTP request	Batched payloads

Rows remain in the client environment throughout the pipeline. Row content does not traverse RowOps servers.

Client Memory Lifecycle

File bytes
    │
    ▼
Parse ──► Parsed rows in memory
    │
    ▼
Validate ──► Valid + Invalid rows in memory
    │
    ▼
Mask ──► Masked rows in memory
    │
    ▼
Transform ──► Transformed rows in memory
    │
    ▼
Export/Sync ──► Blob download or HTTP delivery
    │
    ▼
Garbage collection ──► Memory released

What Is Transient

Row Content

Row data is transient within a pipeline execution:

Not persisted to disk (browser mode): Rows exist only in browser memory
Not persisted to RowOps servers: No evidence found that row content is transmitted to or stored on RowOps infrastructure
Released after pipeline completion: Memory is released when the pipeline completes or the page is closed

Intermediate Representations

Buffers used between masking, transform, and profiling stages are transient:

Created during stage execution
Passed to next stage
Released when no longer needed

Headless Mode Storage

In headless mode, the adapter uses local filesystem storage:

Temporary storage in .rowops/storage/ directory
This storage is local to the execution environment, not server-side

What Is Persisted

Server-Side Persistence

RowOps servers persist metadata, not row content:

Persisted	Content	Row Data Included
Import records	Row counts, status, timestamps	No
Mapping history	Column mappings, preset references	No (fileHeaders removed)
Validation summaries	Error counts by type	No
Audit logs	Actor, action, entity references	No
Usage events	Event type, hostname	No
Sync logs	Session ID, event type	No

What Is Not Persisted Server-Side

No evidence found of server-side persistence for:

Full row-level datasets (CSV/XLSX payloads)
Individual row values (valid or invalid)
Masked or transformed row outputs
Column-level profile aggregates with row samples

Caveat: Usage Tracking

Server-side usage and tracking endpoints accept a strict allowlist of flat fields. Unknown fields are rejected and nested objects are forbidden. Payloads still originate from the client, so treat them as metadata-only and never include row values.

Error Propagation

Validation Errors

Validation errors do not halt the pipeline:

Each row is validated independently
Invalid rows are marked with status and error details
Pipeline continues to completion
Both valid and invalid rows are available in results

Row validation ──► Valid? ──► Yes ──► valid[] array
                      │
                      └──► No ──► invalid[] array
                                    │
                                    └──► {rowIndex, field, code, message}

Invalid Row Availability

Invalid rows remain accessible after validation:

validated[] array contains all rows with status markers
Downstream consumers can inspect error details
Invalid rows can be exported separately for review
Invalid rows do not proceed to Mask/Transform by default

Fatal Errors

Some errors halt the pipeline immediately:

Error Type	Stage	Behavior
Parse failure	Parse	Pipeline halts, no rows returned
`MaskingFailedError`	Mask	Pipeline halts, no fallback
`TransformFailedError`	Transform	Pipeline halts, no fallback
Engine initialization failure	Any	Pipeline cannot start

Fatal errors are fail-closed: no partial results are produced.

Error Information Structure

Validation errors include:

Field	Description
`rowIndex`	Zero-based index of the failing row
`field`	Field key that failed validation
`code`	Error code (e.g., `REQUIRED`, `TYPE_MISMATCH`)
`message`	Human-readable error description

Data Flow Boundaries

Client-to-Server Boundary

Data that crosses from client to RowOps servers:

Import metadata (row counts, not row content)
License verification requests
Usage tracking events
Audit log entries

Data that does NOT cross to RowOps servers:

Row content
Cell values
File bytes
Masked/transformed outputs

Client-to-Target Boundary

Data that crosses from client to user-configured targets:

Sync payloads (batched row data)
Webhook event payloads

This delivery is client-direct: the client sends data to the target without proxying through RowOps servers.

Memory Considerations

Browser Mode

Large files may approach browser memory limits
No automatic disk spillover in browser

Headless Mode

Local storage provides some spillover capability
Memory limits depend on Node.js configuration
Large datasets may require chunked processing

What This Page Does Not Cover

Security implications of data handling (see Data Handling)
Tier-based row limits (see Limits and Quotas)
Specific module behavior (see Modules section)

Where Rows Exist​

Stage-by-Stage Location​

Client Memory Lifecycle​

What Is Transient​

Row Content​

Intermediate Representations​

Headless Mode Storage​

What Is Persisted​

Server-Side Persistence​

What Is Not Persisted Server-Side​

Caveat: Usage Tracking​

Error Propagation​

Validation Errors​

Invalid Row Availability​

Fatal Errors​

Error Information Structure​

Data Flow Boundaries​

Client-to-Server Boundary​

Client-to-Target Boundary​

Memory Considerations​

Browser Mode​

Headless Mode​

What This Page Does Not Cover​