Skip to content

Don't fail concurrent comms credential requests for the same tab session - #9020

Draft
cstns wants to merge 1 commit into
mainfrom
9019-comms-credentials-concurrent-requests
Draft

cstns wants to merge 1 commit into
mainfrom
9019-comms-credentials-concurrent-requests

Conversation

@cstns

@cstns cstns commented Oct 22, 2026

Copy link
Copy Markdown
Contributor

Closes #9019

POST /teams/:id/comms-credentials goes through createClient, which looks up the existing broker client for the username, destroys it, then creates a new one. The username for a team frontend client is built from the tab's sessionId, and that lives in sessionStorage, which the browser copies into duplicated and restored tabs. So after a browser restore several tabs ask for the same username at the same moment, both get past the destroy, and the second insert hits the username primary key and 500s. The tab's team connection treats a credential failure as terminal, so that tab stays without live updates until it's reloaded. That's FLOWFUSE-BACKEND-9X in Sentry (176 events, 44 users).

The insert is now an upsert on the username, so concurrent requests can't collide and the last one written wins, which is already what happens when they arrive one after the other. The destroy stays as it is, since some callers look the existing client up by owner rather than by username.

Reproduced locally by firing 4 concurrent requests with one sessionId: two of them 500 every round. With the fix, 20 out of 20 came back 200. Added a route test for the concurrent case that fails before the fix and also checks the stored password still authenticates through upsert. The controller spec stubs moved from create to upsert, and the broker controller and comms auth tests all pass.

createClient deleted the existing client then inserted a new one, so two requests for the same username could both pass the delete and the second insert hit the primary key. Upsert instead, so the last request wins as it already does when they arrive one after the other.

Closes #9019
@cstns cstns added this to the 3.3 milestone Oct 22, 2026
@cstns cstns self-assigned this Oct 22, 2026
@codecov

codecov Bot commented Oct 22, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.46%. Comparing base (3ef2877) to head (b3e66e8).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #9020   +/-   ##
=======================================
  Coverage   79.46%   79.46%           
=======================================
  Files         475      475           
  Lines       26028    26028           
  Branches     6938     6938           
=======================================
  Hits        20684    20684           
  Misses       5344     5344           
Flag Coverage Δ
backend 79.46% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

This branch was successfully deployed

1 active deployment
staging — b3e66e82 Deployed Oct 22, 2026 by cstns via Deploy application #12681
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Live team updates can stop working in a tab after restoring or duplicating tabs

1 participant