Fix submission stuck on "Saving..." (serialize save effects, backport #5145)

[milanmajchrak]

🎥 Reproduction — before vs after (local DSpace 8.3 Docker stack)

Reproduced end-to-end on a local stack (published dspace/dspace:dspace-8_x-test backend + this frontend). A Playwright script delays every submission PATCH by ~3 s (models a slow save) and fires two overlapping autosaves (two quick edits of the autosave-on-change dc.title field). Same simulated conditions in both runs — only the frontend code differs.

BEFORE (this fork's current code — bug): the second save cancels the in-flight first save mid-transaction (switchMap); commitPending is orphaned true; the second save is silently dropped by the take(1)+filter(!commitPending) guard (only 1 PATCH ever leaves the client); savePending never resets → the footer is stuck on Saving… for the full 18 s window (real user must reload and loses data).

AFTER (this PR — switchMap→concatMap): the saves are serialized; the first completes and clears commitPending before the second runs; Saving… clears within ~4 s.

Objective result logged by the script (identical steps):

run	footer "Saving…" visible during 18 s observation	outcome
before (base branch, switchMap)	visible the entire 18 s	❌ STUCK
after (this PR, concatMap)	gone by t≈4 s	✅ COMPLETED

Full-quality clips/stills in the pr-repro-media branch (before.mp4 · after.mp4). (The media is hosted on the separate pr-repro-media branch, so it is not part of this PR's code changes.)

---

Problem

When creating/editing a submission, the form can get permanently stuck showing Saving.... The user must reload the page, which discards the in-memory ngrx store and loses the metadata they had typed.

Root cause

The four submission save effects in submission-objects.effects.ts use switchMap. When two save actions of the same type overlap, switchMap cancels the in-flight save's inner observable after it dispatched StartTransactionPatchOperationsAction (commitPending = true) but before its response handler runs. Commit/Rollback are dispatched only inside that cancelled observable, so commitPending stays true forever. The next save is then silently dropped by the take(1) + filter(!commitPending) guard in submitJsonPatchOperations(), so no SAVE_*_SUCCESS/SAVE_*_ERROR is emitted, savePending stays true, and the UI is stuck on Saving....

Overlapping same-type saves are easy during normal editing because:

• the dispatchSave guard find(isPending => !isPending) is defeated by startWith(false) in getSubmissionSaveProcessingStatus, so it does not actually serialize saves;
• section/upload/save-for-later saves and save-on-change (on fields with validation errors) dispatch save actions directly without that guard;
• if the submission.autosave.timer is enabled in config, the periodic autosave makes it far more frequent.

Fix

Change the four save effects from switchMap to concatMap. concatMap serializes them, so each inner observable completes (dispatching Commit/Rollback and clearing commitPending) before the next save runs — eliminating the race.

Upstream / backport

This is a backport of upstream DSpace/dspace-angular#5145 (commit a3c14c5f, [DURACOM-453]), which first shipped in DSpace 10.0. The change is not present in any 8.x or 9.x release and was not backported upstream, so DSpace 8.3 (this fork) does not have it.

Scope matches upstream exactly:

• Changed to concatMap: saveSubmission$, saveForLaterSubmission$, saveSection$, saveAndDeposit$.
• Intentionally left as switchMap: depositSubmission$, discardSubmission$, addAllMetadataToSectionData (no commitPending to orphan there).
• The improved catchError from [DSpace-CRIS] Administrative Edit of archived items via submission form and security configuration for metadata visibility (Frontend) DSpace/dspace-angular#5145 is not backported — it depends on parseErrorResponse() and extended error-action signatures that do not exist in 8.3.

Risk & testing

Tiny, low-risk change (1 import + 4 operators). Suggested QA: create a new submission, rapidly edit metadata / switch sections / upload while a save is in flight; confirm the form never gets stuck on Saving.... Full CI/build recommended.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: fa2e305e-584e-4430-b32a-6a139718ce3f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}