Fix 500 in payment status read when a concurrent webhook locks the data element

[Magnusrm]

Description

Problem

GET …/payment (GetPaymentInformation) intermittently returned 500 after a successful payment.

The endpoint persists the latest payment status on read when the requested task is the current task. This races with the payment webhook, which advances the process and locks the payment data element. The persist PUT to storage then fails with 409 - "data element <id> is locked and cannot be updated", which surfaced to the user as a 500 — typically right after returning from the hosted payment page.

Why the existing mitigation missed it

GetPaymentInformation already guarded this race: on a persist failure it called CurrentTaskMovedAwayFrom and only degraded to a read-only result if it could confirm the current task had moved. But the data-element lock can become visible before the CurrentTask change does, so in that window the re-check still saw the payment task as current → the 409 was rethrown → 500. This made it intermittent ("some users").

Fix

Treat a 409/Conflict from t back to read-only paymentstatus, without requiring the task-moved check — the lock itself is the authoritative signal that a c) already finalized things.Non-409 exceptions keep their previous behavior (still propagate when the taskmoved).

Testing

Adds a regression test,GetPaymentInformation_PersistFailsWithLockedDataElement_FallsBackToReadOnly,reproduces the production scel storage needed): the persist throws PlatformHttpException(409, "…is locked…") with the current task left unchanged, and the endpoithe read-only status. Theexisting PersistFailsButTaskUnchanged_PropagatesException test confirms non-409 errors
still propagate.

🤖 Generated with Claude Code

Frontend PR adding retries in order to further harden the process-flow:
Altinn/app-frontend-react#4259

Related Issue(s)

• #{issue number}

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

Documentation

• User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

[coderabbitai]

Warning

Review limit reached

@Magnusrm, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 56 minutes and 44 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more credits in the billing tab to continue.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 82f4f070-dd31-480b-a7d7-fc71baf10659

📥 Commits

Reviewing files that changed from the base of the PR and between b86fb54 and 06a2876.

📒 Files selected for processing (2)

• src/Altinn.App.Api/Controllers/PaymentController.cs
• test/Altinn.App.Api.Tests/Controllers/PaymentControllerTests.cs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/payment-status-read-409-locked-data

---

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 and usage tips.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ivarne]

Looks very reasonable!

Maybe @vxkc could also have a look?