Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue at container connection : Provided user was not an "AzureUser" #20159

Closed
erbox02000 opened this issue Mar 15, 2024 · 1 comment
Closed
Labels
ado Issue is tracked in the internal Azure DevOps backlog bug Something isn't working community-contribution

Comments

@erbox02000
Copy link

Describe the bug

We have integrated fluid framework into our platform, as soon as 2 different users try to connect the same container id, we get an error at the getContainer level : Provided user was not an "AzureUser".

We are using an Azure Fluid Relay and the InsecureTokenProvider.

Our front-end is based on Angular v16 and we are using :

  • fluid-framework: 2.0.0-rc.1.0.3
  • fluid-experimental/data-objects: 2.0.0-rc.1.0.3
  • fluidframework/azure-client: 2.0.0-rc.1.0.3
  • fluidframework/test-runtime-utils: 2.0.0-rc.1.0.3

image

image

image

To Reproduce

To reproduce this issue, we only have to connect the same container with 2 different accounts and sometimes with the same account on different chrome tabs.

Expected behavior

It's obvious, but be able to have multiple users connected to the same container.

@erbox02000 erbox02000 added the bug Something isn't working label Mar 15, 2024
@kashms kashms added the ado Issue is tracked in the internal Azure DevOps backlog label Mar 15, 2024
@pk-pranshu
Copy link
Contributor

A recent change in FRS caused the id and name fields of the IUser to be removed from the quorumMembers snapshot.
1.x clients are generally unaffected, since the Audience was always completely recreated from initialClients. This meant the faulty quorumMembers were never seen by the ServiceAudience. In 2.x the Audience now retains the quorumMembers (as of #12094), so the ServiceAudience does see these faulty members and hits these asserts.
We have made changes #20131 as a minimal mitigation to unblock load on 2.x clients while the service-side fix is made. Once the fix is in, we'll restore these checks to their stronger form.

Please try the release Fluid Framework v2.0.0-rc.2.0.0 and let us know if you see any issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ado Issue is tracked in the internal Azure DevOps backlog bug Something isn't working community-contribution
Projects
None yet
Development

No branches or pull requests

3 participants