Workflow engine: remaining work

[danielskovli]

Description

Consolidated, deduplicated tracking list of all work remaining to close the Workflow engine epic (#16404). Closed sub-issues are already done and excluded here. Check items off as we go — this list is also the input for re-running the gap analysis.

Source issues are linked per item. Where multiple issues cover the same work, all are linked.

A. Backend — engine & service-task behavior

• Park-without-advance for service tasks — let serviceTask.Execute() signal "succeeded, don't auto-advance" and make the Next() loop honour it. (Implicit waiting and error handling in service tasks #18935)
• Persist service-task failure state — when AbortProcessNext fires, write error code/message/details onto the instance/process state (today it only lives in the sync HTTP response and is lost on refresh), and surface it via AppProcessState / ProcessStateEnricher. (Implicit waiting and error handling in service tasks #18935)
• FiksArkiv + eFormidling service tasks — update them to the new process/next methodology now that running process-next from business logic has changed. (Ensure FiksArkiv flows work with new workflow engine #17970)
• PROPOSED: Batch InstanceDataMutator commits — commit changes as batch operations instead of per-element; requires new Storage endpoint(s), needs coordination with #data. (Handover notes: app-lib #19032)

B. Service-task idempotency / correctness

• PDF service task idempotency — clear prior task-generated data elements before regenerating so retries don't duplicate PDFs; lift the cleanup into a shared helper (PdfServiceTask + SubformPdfServiceTask). (Ensure service task idempotency #18888)
• eFormidling idempotency strategy + implementation — decide between accepting MessageAlreadyExistsException, status-querying eFormidling, or a per-workflow idempotency key, then implement. (Analysis: Analysis: eFormidling, handle duplicate message app-lib-dotnet#854; implementation: Ensure service task idempotency #18888)
  • ⚠️ Resolve conflict: Ensure service task idempotency #18888's plan says to mirror RemoveDataElementsGeneratedFromTask, but the handover note says to remove it (per feat: Move task data cleanup responsibility to Storage app-lib-dotnet#1750). Reconcile before either lands.
• Idempotency for Altinn Events emissions — investigate whether it can be added. (Handover notes: app-lib #19032)

C. Frontend

• Implicit waiting step — when parked on a service task with no failure/no layout, render a Feedback-style waiting component that polls via useBackoff() and navigates forward when the engine advances. (Implicit waiting and error handling in service tasks #18935)
• Failure rendering — when the backend reports a service-task failure, render the retry/back UI, reading failure context from backend state (survives refresh). (Implicit waiting and error handling in service tasks #18935)
• De-conflate "service task" vs "PDF service task" in ProcessWrapper.tsx and PdfWrapper.tsx. (Implicit waiting and error handling in service tasks #18935)
• Cypress + backend unit tests — refresh-while-pending, synchronous-passthrough, and failure scenarios; plus an on-demand-callback async service-task test fixture. (Implicit waiting and error handling in service tasks #18935)

D. Config cleanup & migration tooling

• v8→v9 migration/upgrade utility — auto-convert legacy magic-prop PDF (and eFormidling) config to service tasks. (Remove legacy PDF toggle from applicationmetadata.json #19012, Deal with migration script v8 -> v9 #19081)
• Remove enablePdfCreation from the DataType model; switch app-template to the service-task PDF approach; update docs. (Remove legacy PDF toggle from applicationmetadata.json #19012) (implemented in feat: Add applicationmetadata analyzer, enforce deprecation of enablePdfCreation and legacy eFormidling config #19304)
• Remove legacy eFormidling config from applicationmetadata.json / Application model (alongside the PDF removal above). (Remove legacy PDF toggle from applicationmetadata.json #19012) (implemented in feat: Add applicationmetadata analyzer, enforce deprecation of enablePdfCreation and legacy eFormidling config #19304)
• PROPOSED: ApplicationMetadata validator — basic startup-service that performs validation of applicationmetadata.json. Start with a few relevant checks related to deprecations 👆, add more later if desired. (Handover notes: app-lib #19032) (implemented in feat: Add applicationmetadata analyzer, enforce deprecation of enablePdfCreation and legacy eFormidling config #19304)

E. Build / release & code hygiene

• PROPOSED: Experimental publishing for app-lib in the monorepo. (Handover notes: app-lib #19032)
• Deduplicate shared models between app-lib and workflow-engine (watch the NuGet lifecycle constraint). (Handover notes: app-lib #19032)
  • Kept duplicated logic, added tests/guards ( implemented in test: guard workflow-engine wire contract against app/engine drift #19299)

F. Open decisions that gate shipping (decide, then possibly implement)

• Workload identity for the DB connection pool — how it behaves with npgsql, impact on pool size. (Workload identity for db connection pool? #18544)
• Rate limiting / throttling callback targets with high failure rates — mechanics still undecided. (Implement rate limiting for callback targets with high failure rate? #18481)

G. Manual testing & app verification

• Manual test against app-lib v9 + workflow engine: Payment app.
• Manual test against app-lib v9 + workflow engine: brukerstyrt-signering app.
• Manual test against app-lib v9 + workflow engine: service-tasks app.
• Verify candidate app: ssb/ra0536-01.
• Verify candidate app: ssb/ra0574-01.
• Verify candidate app: brg/aarsregnskap-funk-202405.

[maxim-ultra]

Hi - I looked at #19280 from the payment-reliability angle. One risk worth isolating is: Public issue mentions payment, retry, idempotency, duplicate; Workflow engine: remaining work.

A useful first check: map payment authorization, spending limits, receipt evidence, and circuit-breaker behavior. I would keep it public-only: no production access, no API keys, no wallet access, and no private customer data.

If useful, I can turn this into a compact Agent Payment Reliability Audit: prioritized findings, repro notes, patch-level recommendations, and buyer-facing summary.