When creating a folder in a, MS Team connected, SP site default documents library and afterwards create a Channel with the same name from within Teams, these two were previously magically and automatically connected to each-other so you can see the contents of the created folder directly from the Channel 'files' tab. That is what we expect to happen in both English and (in our case) Dutch sites.
The same method is also mentioned in Laura Kokkarinen's blog @LauraKokkarinen and used to work fine for a long time.
We see that in, MS Team conneced, SP sites with the Dutch base language we get an error in MS Teams when navigating in the Channel to the files tab.
Exception encountered from Sharepoint for requestId 6ee7129f-60bc-0000-4971-317df438dcb1 Scenario ID: 1382
Tenant: https://enctbxrmtst.sharepoint.com/
So the connection to the already created folder is not correct. In SP sites with the English base language (the same base language as the root site of our tenant) and with an English user opening the 'files' tab this still works fine.
So only the combination of an English Root site, English Teamsite and English profile user language is still working fine, all other seem to fail.
Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.
We see the same issue appear recently in all our own and our customer's tenants. We saw it working fine last monday (28 october). When we now try to do the same in older Teams where we provisioned both the folders and the corresponding channels, it's also failing. So it seems that it's some mechanism inside the Teams 'files' tab functionality which has changed and caused these issues.
@advdberg I cannot reproduce this but I might have missed a step somewhere (or my profile isn't properly updated to Dutch). When you see this issue, do you have the "old" files tab or the "new" files tab in Teams (the new one is with the views and resembles the SharePoint doc lib)?
In any case, while this might have worked before, I believe this was an unsupported side effect of how Teams handled folder creation. I know that the PG has been looking into renaming scenario's as well as introducing the new files experience. I can imagine any of these breaking this undocumented behavior.
If a folder needs to be connected to a channel, I'd suggest letting Teams be in control by creating the channel first and then applying site designs or calling PnP.
I posted to the PG asking if this was even an intended, supported scenario to begin with. Hopefully I'll get an answer soon.
@YannickRe thanks for your reply!
I got some signs that it's working again. We will further test it now over multiple tenants to check if it's resolved everywhere it used to fail yesterday.
We got this view (so looks like the "old" files tab):

and then after a few seconds the stated error message.
To come back to your suggestion about letting Teams to be in control, the issue is that when you request a new Channel via Graph API, the channel is created but the SP folder won't be available (yet), unless you navigate as a user in Teams to the Files tab in the created Channel. It seems like that action triggers the creation/connection of the folder in SharePoint. If you wan't to do customizations to the folder while provisioning the whole bunch, you'll have to provision the folder up front (or afterwards, but that has the same effect).
Good to hear! The Product Group let鈥檚 me know that they didn鈥檛 consider this scenario, so it鈥檒l be better if you could find an alternative.
I鈥檒l share your use case with them, they might come up with an alternative approach too.
I get reports from other environments and customers that it's also fixed there.
What we do see is that the 'Go to channel' button and 'Message' are not visible in the 'pre-created' Channel folder in SharePoint. I guess that the folder properties such as 'vti_teamchannelurl' are indeed only set when Teams is creating the channel folder.
It would be nice if there's a better/supported way of automating the Channel folder creation, while in our opinion is the possibility to provision a default file/folder structure in it is crucial from a functional perspective. A small sidenote is that we now in some use cases also apply permissions to this Channel folder but that will hopefully no longer be needed with the introduction of private Channels.
Since you're saying it appears fixed, I'll mark this issue as resolved...
Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues