Forum Discussion

dbeavon3's avatar
dbeavon3
Icon for Memorable Member rankMemorable Member
4 months ago

Buggy DW/SQL endpoints - Retrieval of MWC token used for accessing storage failed

Using Fabric has been a living nightmare for the past two weeks.  I'm in the NCUS region and I've spent dozens of hours working on cases.  It can take several days to get the PG to engage on our bugs...
data engineering
v-anbandari's avatar
v-anbandari
Icon for Community Support rankCommunity Support
3 months ago

Hi dbeavon3 ,
thank you for the additional context.

@@version returns the version of the SQL engine used by the SQL analytics endpoint, not the lakehouse or deployment state. 

The SQL analytics endpoint is a read-only T‑SQL layer over Delta tables in OneLake, so it operates independently from lakehouse data changes or deployments.

So, this version will not change based on deployment success, failure, or rollback behavior it is managed at the platform level.

 

Thank you.

dbeavon3's avatar
dbeavon3
Icon for Memorable Member rankMemorable Member
3 months ago

Yes, it changes after deployments.  It literally shows the date the new version was created, for the SQL engine.  Did you try it?

This engine is certainly the thing that breaks or behaves differently from one upgrade to the next (not the delta).

  • v-anbandari's avatar
    v-anbandari
    Icon for Community Support rankCommunity Support
    3 months ago

    Hi dbeavon3 ,

    I meant the version will not change based 

     I'm guessing when there is a failed deployment, then we would see this number changing in one direction and then back again in the other.

    on this behaviour.

    But for further info on the Mwc token you are facing, please check this previosly raised thread in the community and check if it helps:
    Solved: Spark sql execution for SPN fails with mwc token e... - Microsoft Fabric Community

    Thank you.


    • dbeavon3's avatar
      dbeavon3
      Icon for Memorable Member rankMemorable Member
      3 months ago

      Hi v-anbandari @ 


      I come to learn that it was another bug (a "FS" switch in the NCUS region that was enabled without sufficient testing).

      I have been trying to discuss with Microsoft FTE's on that team (names Rake**, Shuv**, Charith, Srini*****) but they won't share any details about the reason the bug impacted us - despite the fact that our solutions were down for TWO full days.

       

      This is a pretty frustrating experience and is becoming pretty common for us in Fabric.  It is not a good place for customers to run mission-critical workloads.  Even when we encounter multi-day outages, Microsoft simply doesn't care, and refuses to help us to understand them.  My opinion is that we need to reduce our Fabric usage by at least 50% or more, given that it isn't a trustworthy platform and there is little support offered during outages.

      • v-anbandari's avatar
        v-anbandari
        Icon for Community Support rankCommunity Support
        3 months ago

        Hello dbeavon3,
        We acknowledge your feedback and understand your frustration regarding the outages and the impact on your workloads.

         

        We would request you to continue coordinating with the Support and PG teams, as they would be in the best position to provide further details and updates on the backend investigation. From the community side, visibility into these internal deployment and feature switch activities is unfortunately limited.

        Thank you.