c2fb027c41
* Avoid null endpoint DTO metadata in tests * Enforce console logs hub read permission * Remove unused console logs hub import * Support mapped endpoint metadata in auth tests * Reduce console log capture throughput impact * Address Copilot console logs review * Refactor task scheduling to support tenant-level background work and enhance logging functionality. * Introduce ConsoleStreamHook for stdout/stderr tee and enhance logging validation. Adjust test cases and startup warnings for distributed lock provider usage. * Refactor console logging pipeline with capture optimization and new ConsoleLogsHost; update tests accordingly. * Add Ansi SGR parser for console logs and associated unit tests * Remove ANSI color renderings and parsers; integrate ConsoleLogScopeAccessor for improved logging context with workflow instance ID support. * Address console logs code quality feedback * Address PR review feedback * Preserve console logs extension points * Stabilize console logs host lifecycle * Address final automated review comments * Tighten console log capture shutdown * Address console log review feedback * Address follow-up review feedback * Cover final review feedback * Avoid recursive console provider initialization * Guard console host lease shutdown * Preserve console log scope and provider lifetime * Correlate console log scope fallback * Tighten console scope correlation * Expose host services during provider construction * Redact ANSI-normalized console lines * Remove `ConsoleCaptureTee` and related services and tests * Use pipeline contributors for console log context * Update CShells package versions to 0.0.24-preview.132 * Filter live console logs by workflow instance * Enhance console logging with activity execution metadata and extend test coverage. * Address console logs stream consumption comment * Add diagnostics OpenTelemetry backend * Introduce dedicated workflow JSON type registry and hardening This change addresses GitHub issue #7541 by establishing a separate type registry (`IWorkflowJsonTypeRegistry`) for workflow JSON serialization. This decouples workflow type resolution from expression type aliases, enforcing a strict trust boundary. Key aspects: - New workflow JSON emits preferred aliases for registered types. - Existing persisted workflows can be loaded via registered legacy names. - Unknown, abstract, interface, open generic, or inappropriate collection types are rejected during deserialization, enhancing security. - Public APIs (e.g., incident strategies) now expose consistent workflow JSON type identifiers. This ensures secure, predictable, and backward-compatible handling of types within workflow definitions and payloads. * Remove unused project references and streamline console log endpoint * Move serialization type aliases to Elsa.Common * Update serialization integration fixtures for aliases * Stabilize missing rate limiter policy test
21 lines
861 B
Markdown
21 lines
861 B
Markdown
# Data Model: Workflow JSON Type Hardening
|
|
|
|
## SerializationTypeOptions
|
|
|
|
- Stores workflow JSON aliases mapped to concrete types.
|
|
- Stores optional legacy names mapped to the same concrete types.
|
|
- Provides default primitive and JSON island aliases needed by workflow payloads.
|
|
- Lives in `Elsa.Common` so non-workflow serialization layers can share the same trust boundary.
|
|
|
|
## SerializationTypeRegistry
|
|
|
|
- Runtime registry built from `SerializationTypeOptions`.
|
|
- Resolves aliases and registered legacy names to types.
|
|
- Lists registered types for compatibility resolution.
|
|
- Returns preferred aliases for writing new workflow JSON and public descriptor values.
|
|
|
|
## Workflow Type Identifier
|
|
|
|
- Alias: preferred stable identifier for new workflow JSON.
|
|
- Legacy name: supported compatibility identifier for previously persisted workflow JSON or older clients.
|