Forum Discussion

BogdanL's avatar
BogdanL
Advocate I
1 month ago

Fabric GraphQL — Decimal scalar broken in variables: mutations fail for any non-integer value

Environment

  • Microsoft Fabric — API for GraphQL
  • Data source: SQL Database in Fabric (not Warehouse)
  • Column definition: [Price] DECIMAL(18,4) NOT NULL
  • GraphQL scalar in the auto-generated schema: scalar Decimal

Description

I'm experiencing a bug with the Decimal custom scalar when passing values through GraphQL variables. Saving non-integer decimal values (e.g. 1.42) always fails, while integer values (e.g. 1, 2) are accepted without any issue.

The bug is fully reproducible on any mutation that uses a Decimal-typed variable.

Could the Fabric GraphQL / DAB team confirm whether this is a known issue, and provide either a target fix version or a supported variable format that works?

The SQL column:

CREATE TABLE [dbo].[ItemPrice]
(
    [Id]                    BIGINT        IDENTITY(1,1) NOT NULL,
    [PriceListItemId]       BIGINT        NOT NULL,
    [CustomerPaymentTypeId] BIGINT        NOT NULL,
    [Price]                 DECIMAL(18,4) NOT NULL,
    ...
)

The auto-generated GraphQL type and input types:

input CreateItemPriceInput {
  PriceListItemId:       Long!
  CustomerPaymentTypeId: Long!
  Price:                 Decimal!
  UserCreate:            String!
  UserLastUpdate:        String!
  ...
}

 

Attempt 1 — Inline literal ( Works)

When the value is hardcoded directly in the query document, the mutation succeeds:

mutation CreateItemPrice {
  createItemPrice(
    item: {
      Price:                 1.42
      CustomerPaymentTypeId: 9
      PriceListItemId:       17
      UserCreate:            "bg"
      UserLastUpdate:        "bg"
    }
  ) {
    Id
    PriceListItemId
    CustomerPaymentTypeId
    Price
    UserCreate
    UserLastUpdate
  }
}


Attempt 2 — Variable typed as Decimal!, passed as JSON number ( Fails)

mutation CreateItemPrice($Price: Decimal!) {
  createItemPrice(
    item: {
      Price:                 $Price
      CustomerPaymentTypeId: 9
      PriceListItemId:       17
      UserCreate:            "bg"
      UserLastUpdate:        "bg"
    }
  ) {
    Id
    PriceListItemId
    CustomerPaymentTypeId
    Price
    UserCreate
    UserLastUpdate
  }
}

Variables (Postman):

{ "Price": 1.42 }

Error response:

{"errors": [{"message": "Decimal cannot parse the given value of type `System.Double`."}]}

 

Attempt 3 — Variable typed as Decimal!, passed as JSON string ( Fails)

Same mutation as Attempt 2, variables:

{ "Price": "1.42" }

Error response:

{"errors": [{"message": "Decimal cannot deserialize the given value."}]}

 

Expected behaviour

Both of the following variable formats should be accepted by the Decimal implementation, consistent with how other GraphQL servers handle custom decimal scalars:

{ "Price": 1.42 }

{ "Price": "1.42" }

 

Thank you!

UPDATE 2026-07-29:
Looking to escalate the issue to Microsoft GraphQL/DAB team.

3 Replies

  • Based on the behavior you've described, this appears to be related to the Decimal custom scalar implementation in Microsoft Fabric API for GraphQL, rather than an issue with your SQL column definition or mutation structure.

    Your testing already isolates the problem well:

    • Inline GraphQL literal (Price: 1.42) works.

    • Variable passed as JSON number (1.42) fails because it is interpreted as System.Double.

    • Variable passed as JSON string ("1.42") fails because the scalar does not deserialize the string format.

    The error:

    Decimal cannot parse the given value of type `System.Double`.

    suggests that the GraphQL runtime is receiving the JSON numeric value as a floating-point type before converting it to Decimal. Since floating-point values can introduce precision issues, many GraphQL implementations handle decimals by requiring a specific scalar serialization format.

    As a workaround, you can try passing the value as a GraphQL variable using a format supported by the current Decimal scalar implementation, such as avoiding floating-point conversion where possible. For example, if your client supports it, try sending the value as a JSON string with the exact decimal representation. However, based on your test, it appears this specific implementation currently does not support that path either.

    Given that:

    • DECIMAL(18,4) is correctly defined in Fabric SQL Database.

    • The same value succeeds as an inline literal.

    • Both common variable serialization formats fail.

    This looks like a potential bug or limitation in the Fabric GraphQL Decimal scalar variable deserialization path.

    Recommended next steps:

    • Capture the Fabric workspace ID, GraphQL API details, request payload, and correlation IDs.

    • Open a Microsoft Support ticket or raise this through the Fabric community/product feedback channels so the GraphQL/DAB team can investigate.

    • Include the reproducible examples you provided, as they clearly demonstrate the difference between inline literals and variables.

    For reference:

    At this stage, there does not appear to be a configuration change on the SQL side that would resolve this; the issue is most likely within the Decimal scalar handling in the GraphQL layer.

    💡 Helpful? Give a Kudos 👍 — keep the community growing.

    Solved your issue? Mark this as the Accepted Solution ✔️

    Best regards, Prince Singh | Data Science & Microsoft Fabric Enthusiast

  • v-kathullac's avatar
    v-kathullac
    Community Support

    Thankyou @Prince0011  for Addressing the issue.

     

    Hi BogdanL ,

    Thank you for reaching out to Microsoft Fabric Community Forum,

     

    As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided for the issue worked? or Let us know if you need any further assistance?

     

    Regards,

    Chaithanya

  • v-kathullac's avatar
    v-kathullac
    Community Support

    Thankyou @Prince0011  for Addressing the issue.

     

    Hi @BogdanL ,

    Thank you for reaching out to Microsoft Fabric Community Forum,

     

    As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided for the issue worked? or Let us know if you need any further assistance?

     

    Regards,

    Chaithanya