Skip to content

[Feature] F3.3: Published-package compatibility validation #8219

Open
3 of 4 issues completed
Open

Description

@sfmskywalker

Program: #8194
Parent: #8198
Planning ID: F3.3

Outcome and scope

Run clean NuGet consumer builds/host smoke tests for supported Elsa versions and TFMs; catch accidental unreleased-core dependencies and schema compatibility regressions. Include server/Studio API and paired-package compatibility.

Acceptance criteria

  • Deliver the specified capability and demonstrate each behavior above with targeted checks or documented research evidence.
  • Preserve existing package/activity identities and supported contracts, or provide an explicit migration.
  • Document setup, limitations, dependencies and verification results.

Readiness

In progress. Original proof-version upgrades are accepted through #8632; stable 3.10.0 SQLite upgrades are accepted through #8644/#8639. Native child #8643 retains the paired server/Studio browser/package scope and waits for the recorded Hosted routing decision. Native child #8661 now owns package readiness for seven Admission/Connections modules and is In Progress / Assigned / Verification Pending. Its sole prerequisite #8658 is accepted through merged #8660 at a866284727cce19068b417a908bbe4a2573815d5. #8661 is the program's sole active delivery Task; this feature's full acceptance remains open.

Follow AGENTS.md, existing test/ conventions and dated ADRs under doc/adr/. Scope is Elsa 3 unless explicitly a portability assessment. Repository consolidation includes Core, all Extensions, and Studio; release boundaries remain explicit and independent.

Hierarchy: native parent/sub-issue relationships verified on 2026-09-23. Explicit blocking dependencies are configured separately; Markdown links remain references. See #8194.

Accepted persisted-upgrade evidence — 2026-10-06

#8632 merged into the program branch at e69d92f57de4546a4dd9fd4015d8b8eeba7d1b92; #8629 is closed with all eight scoped criteria verified. Exact head a5b1eb711c30331e0708719e1090bae4d280e6f9 passed independent APPROVE + HIGH, Greptile 5/5 and all applicable CI. The hosted six-cell proof and lead artifact/database audit verify direct 3.8.4/3.9.0 upgrades across net8/net9/net10 against the unchanged unpublished proof artifact.

This is SQLite/default-tenant/built-in-activity evidence, not certification of every provider or activity family. #8631 / #8635 has accepted a distinct stable 3.10.0 candidate under #8220 with passing representative consumers. Native child #8639 is accepted through merged #8644 at 306cbaf5465f7d54d2876b5e4b8a4b6e3a12824b. Final lead acceptance verifies all six stable-byte SQLite cells, original proof regression, retained evidence and exact-head gates. The accepted original artifact and envelope remain unchanged. Paired browser compatibility is still unverified and now owned by #8643. Final program integration into main, publication and publisher cutover remain separate gates.

Remaining paired compatibility and package readiness

Native child #8643 retains the stable-byte server/Studio host/browser proof: all four supported NuGet host entrypoints across net8/net9/net10 and aligned 3.8.4/3.9.0/3.10.0 records, with exact package and executed browser-asset provenance, including the full optional-profile matrix. It waits for its recorded Hosted routing decision; no browser acceptance is claimed. Its input dependency #8631 is closed. The dependency-update ownership and publication/cutover gates remain separate.

Native child #8661 prepares seven existing Admission/Connections modules for package consumption with reviewed API/schema/eligibility baselines, one coherent unpublished artifact closure, six TFM/feature build cells and twelve real PostgreSQL scenario records. Each cell proves the guarded Admission host and a separate isolated positive managed-secret/exact-instance-grant host. The accepted first-release lockstep policy applies; optional providers and the future Socket bridge are outside this prerequisite. All future connector, live Slack, original browser matrix and publisher outcomes remain required.

#8661 is In Progress / Assigned / Verification Pending; native prerequisite #8658 is closed and accepted. No second implementation task is active. Fresh candidate bytes, exact-head hosted compatibility proof and independent review are required; historical accepted candidate evidence cannot be repurposed for new packages. Publication requires its own concrete authorized action.

Activity

  1. added
    elsa 3This issue is specific to Elsa 3
    enhancementNew feature or request
    prio highIs on the roadmap for the near-future
    on Sep 23, 2026
  2. sfmskywalker commented on Oct 6, 2026

    @sfmskywalker
    MemberAuthor

    Acceptance audit for the next bounded compatibility slice: official NuGet indexes currently contain 3.8.4 and 3.9.0 for Elsa, Elsa.Persistence.EFCore.Sqlite, Elsa.WorkflowContexts, Elsa.Studio.WorkflowContexts and Elsa.Studio.Core; they do not yet contain 3.10.0. Existing #8313 acceptance covers released 3.8.4 descriptor/definition import and negative mutations, not a persisted workflow-instance/bookmark resumed across package versions. The accepted #8275 Secrets plan is separate-DB re-entry/rotation and does not establish runtime schema migration.

    After #8626 has a verified local consolidated package set, the smallest next rehearsal is two isolated package-only processes: published 3.9.0 with EF Core SQLite persists a suspended workflow; the consolidated package consumer applies the normal schema migrations, loads and resumes it, and asserts definition/activity identity, typed persisted inputs, bookmark handling and terminal output/state. Keep the released baseline and candidate artifacts/caches/processes separate. This is prepublication compatibility evidence, not a claim that 3.10 packages are published or that every older 3.8 upgrade/provider combination is supported. The broader supported-upgrade matrix, including 3.8.4, remains to be explicitly verified and recorded.

    Primary package indexes: https://api.nuget.org/v3-flatcontainer/elsa/index.json and https://api.nuget.org/v3-flatcontainer/elsa.persistence.efcore.sqlite/index.json . Prior definition evidence: #8313 (comment) . This refinement does not open a competing active task; #8626 remains active.

    Read-only fixture refinement (2026-10-06): use two standalone consumers with Elsa and Elsa.Persistence.EFCore.Sqlite, separate caches/processes and explicit management/runtime SQLite files. The released process publishes a small workflow with fixed definition and instance identities, typed input/output metadata and an Event bookmark, then exits after verifying durable suspension. The candidate starts against the same files through normal migration startup, verifies the saved identities/bookmark/input, resumes by bookmark ID and checks bookmark consumption plus the expected terminal state/output. Inspect both migration histories; successful startup alone is insufficient.

    The required public seams (CreateClientAsync, CreateInstanceAsync, RunInstanceAsync, RunWorkflowInstanceRequest.BookmarkId, WorkflowDefinitionPublisher.NewAsync and normal Database.MigrateAsync startup) were checked in the exact 3.8.4, 3.9.0 and current Core main sources. A separate 3.8.4 baseline appears feasible without API shims; runtime execution is still required. Definition authoring must explicitly populate input/output metadata: NewAsync(root) serializes the root activity but does not transfer workflow-builder metadata. Leave OriginalSource unset to avoid the historical import-precedence difference. This design is preparation, not a passed compatibility test or a second active delivery task.

    Source pointers at Core main: definition creation, runtime client, normal migrations.

  3. sfmskywalker commented on Oct 6, 2026

    @sfmskywalker
    MemberAuthor

    Read-only readiness audit at PR #8635 head ba5b348aa2414fdf7c19d9d8806e87b7c91a4205, independently reviewed by Sol 6.1 High and checked by the lead:

    The existing C# suspend/resume/fresh-process verification lifecycle can be reused for the stable candidate. The Python runner currently selects target provenance and receipt identity through fixed PROOF_VERSION, PROOF_SOURCE, run and artifact constants. A future bounded compatibility task needs a separately validated stable input adapter and a shared target-identity parameter; it must preserve the existing pinned proof adapter, default command and negative contracts. No implementation or second active Task has started.

    The stable adapter must consume the accepted #8631 original archive and separate envelope using the existing archive verifier, with no rebuild, relabel or package publication. Fixed retrieval without checkout must verify live artifact metadata before transferring original bytes into token-minimal execution. Candidate source/run/artifact identity and the later matrix fixture source/run are different identities and must both be recorded. The representative five-package consumer requirement must not be copied onto this two-package persisted fixture; reuse its archive/cache/runtime corroboration at the appropriate scope.

    Acceptance remains all six 3.8.4/3.9.0 × net8/net9/net10 cells, 18 lifecycle processes, normal migrations, original workflow/input/sentinel/bookmark identity, saved-bookmark resumption, durable typed output and fresh terminal verification. Preserve immutable baseline snapshots, synthetic database bytes/hashes, allowlisted command outcomes, and fail-closed negative cases. A fresh original-artifact availability check is required at compatibility acceptance and again before publication. SQLite/default-tenant/built-in-activity limits remain explicit; paired server/Studio outcomes and other applicable feature gates remain open.

    The exact stable candidate identity has not yet been produced or accepted. #8631 remains the sole active Task; #8636 remains the next ready Task. This audit neither closes #8219 nor authorizes publication.

  4. sfmskywalker commented on Oct 6, 2026

    @sfmskywalker
    MemberAuthor

    Paired compatibility preparation (not runtime acceptance)

    A read-only source/package audit identified four declared Studio consumer entrypoints: Blazor Server, standalone WebAssembly, ASP.NET-hosted WebAssembly, and native CustomElements embedding. Current source and the released 3.8.4/3.9.0 Studio tags declare net8/net9/net10. The accepted 3.10.0 candidate contains the corresponding Studio libraries and six browser assets; all four Host.* executables are nonpackable exclusions. Later package-only fixtures must reproduce the real host compositions with exact PackageReferences rather than request nonexistent Host.* nupkgs or fall back to project references.

    The proposed coverage ledger accounts for 12 current-candidate host/framework cells and the applicable aligned 3.8.4/3.9.0 baseline records. Full-shell journeys need real workflow APIs, designer callbacks and save/reload/run behavior, package-owned browser assets, and the distinct WASM delivery paths; CustomElements needs its actual embedding journey. Existing WorkflowContexts HTTP/component evidence is useful but is not this broader acceptance. WASM provenance must establish the bytes executed in the browser, not merely server-side assembly loads.

    The accepted lockstep ADR calls for matching Elsa package versions. This audit does not invent support for arbitrary mixed server/Studio releases. Detailed released-package framework assets and conditional host composition remain to be reconciled before making the next paired Task ready. Source declarations and package existence alone are not runtime passes. Npm publisher ownership remains a separate gate; it does not block the NuGet browser proof.

    #8639 remains the next-ready Task and #8636 the sole active delivery Task. No paired fixture was implemented or executed, and this preparation does not satisfy or close this Feature. The later Task should reuse the original accepted candidate archive/verifier, shared package isolation helpers and one reusable host/browser journey; it should not produce a separate Task for every cell.

    Sources: accepted lockstep ADR, 3.8.4 Studio framework declaration, 3.9.0 host compositions, accepted candidate evidence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    elsa 3This issue is specific to Elsa 3enhancementNew feature or requestprio highIs on the roadmap for the near-futuretriaged

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions