Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions effect/architecture.md
Original file line number Diff line number Diff line change
Expand Up @@ -79,7 +79,7 @@ The `Run` method wraps the user-defined method (`Junctions()` or `RunInternal`)

The `EffectRunner` coordinates all registered effect providers. It builds its provider list at construction time by querying `IEffectProviderFactory` instances filtered through the `IEffectRegistry`.

It exposes three operations that fan out to every active provider:
It exposes three operations that fan out to every active provider, awaiting each provider sequentially:
- **`Track(model)`** — Register a new model for tracking (e.g., add `Metadata` to the EF change tracker)
- **`Update(model)`** — Notify providers of an in-memory mutation (e.g., re-serialize parameters after output is set)
- **`SaveChanges(ct)`** — Persist all accumulated changes across all providers
Expand Down Expand Up @@ -173,7 +173,7 @@ Junctions execute inside the "Execute Train Chain" box. Each mutation to the tra

### DataContext

`DataContext<TDbContext>` extends EF Core's `DbContext` and implements both `IDataContext` and `IEffectProvider`. It maps `Track` → `Add`, `Update` → EF `Update`, and `SaveChanges` `SaveChangesAsync`, delegating persistence to EF Core's change tracker. It also provides transaction support via `BeginTransaction`, `CommitTransaction`, and `RollbackTransaction`.
`DataContext<TDbContext>` extends EF Core's `DbContext` and implements both `IDataContext` and `IEffectProvider`. It maps `Track` and `Update` to direct entity state assignment (Added for new entities, Modified for existing), and `SaveChanges` to `SaveChangesAsync`. State is set on the target entity only — navigation properties are not traversed, which prevents unnecessary UPDATE statements when entities cross DI scope boundaries (e.g., metadata loaded by `LoadMetadataJunction` passed into a child train's context). It also provides transaction support via `BeginTransaction`, `CommitTransaction`, and `RollbackTransaction`.

**DbSets:**

Expand Down
2 changes: 1 addition & 1 deletion sdk-reference/scheduler-api/add-trax-job-runner.md
Original file line number Diff line number Diff line change
Expand Up @@ -167,7 +167,7 @@ Maps a `POST` endpoint at the specified route that:
3. Creates a new DI scope and resolves `IJobRunnerTrain`
4. Calls `Run(new RunJobRequest(metadataId, input))`
5. Returns `200 OK` with a `RemoteJobResponse` containing the metadata ID on success
6. On error: returns `200 OK` with `RemoteJobResponse.IsError = true` and structured error fields (`ErrorMessage`, `ExceptionType`, `StackTrace`)
6. On error: logs the exception, then returns `200 OK` with `RemoteJobResponse.IsError = true` and structured error fields (`ErrorMessage`, `ExceptionType`, `StackTrace`)

### UseTraxRunEndpoint

Expand Down
4 changes: 2 additions & 2 deletions sdk-reference/scheduler-api/trax-lambda-function.md
Original file line number Diff line number Diff line change
Expand Up @@ -164,9 +164,9 @@ To minimize cold start time:

## Error Handling

For `Execute` requests, exceptions are caught and returned as a `RemoteJobResponse` with structured error fields (`IsError`, `ErrorMessage`, `ExceptionType`, `StackTrace`). The `LambdaJobSubmitter` on the scheduler side does not read this response (fire-and-forget), but the error is persisted in the Lambda function's metadata.
For `Execute` requests, exceptions are logged and returned as a `RemoteJobResponse` with structured error fields (`IsError`, `ErrorMessage`, `ExceptionType`, `StackTrace`). Errors that occur within the train itself are also persisted to the `Metadata` table by `ServiceTrain.Run`. However, pre-train errors (e.g., deserialization failures) only appear in the log output. The `LambdaJobSubmitter` on the scheduler side does not read the response (fire-and-forget).

For `Run` requests, `ITraxRequestHandler.RunTrainAsync` returns a `RemoteRunResponse` that may contain structured error fields. The `LambdaRunExecutor` on the scheduler side reads the response and reconstructs a `TrainException` with the full error context.
For `Run` requests, exceptions are logged before being rethrown. `ITraxRequestHandler.RunTrainAsync` returns a `RemoteRunResponse` that may contain structured error fields. The `LambdaRunExecutor` on the scheduler side reads the response and reconstructs a `TrainException` with the full error context.

## See Also

Expand Down