Value which I am storing is not returned when I queried the record back

Question

Value which I am storing is not returned when I queried the record back

Mahesh Raja Mahalingam 81

Hi Team,

I my cosmos (NoSql) database i am storing a record with a value (tripID: 18031765881344672) , But when I query the same record it gave me the record with different tripID value (18031765881344670) . Somehow the cosmos is rounding off I believe. Has anyone encountered such issue. Its Scarry !!! How Can I fix this ? or What is the alternative solution

User's image

1 answer

Your answer

Answer 1

VRISHABHANATH PATIL 4,825 Microsoft External Staff Moderator

Hi @Mahesh Raja Mahalingam

It looks like you’re having issues retrieving the correct tripID from your Azure Cosmos DB. This can be quite concerning, especially if you believe that it might be rounding off values. Let’s see if we can narrow down what’s happening.

Potential Reasons and Solutions:

Data Type and Precision: Ensure that the data type for tripID can handle large numbers. If you're storing tripID as an integer, it might lead to rounding issues. Consider storing it as a string to preserve the value as is.

Query and Indexing: Double-check your query syntax. If you're using indexes, ensure that the indexing policy you’ve set covers the properties you’re filtering on, as unindexed properties may result in unpredictable behavior.

Schema Constraints: If you are using Azure Synapse Link or similar features, know that there are schema constraints, like property limits (1000 properties) or depth limits (127 nested properties) that might cause properties to replicate as NULLs or might miss completely.

Synchronization Delay: If you recently added or modified the record, remember that there might be a delay (usually a few minutes) in syncing between the transactional and analytical stores, leading to discrepancies.

Steps to Troubleshoot:

Check Data Type: Confirm that tripID is stored as a string in your Cosmos DB.
Review Your Query: Make sure your query correctly references tripID exactly as it's stored.
Examine Indexing Policy: Look at the indexing policy to check if tripID is included.
Test Synchronization Delay: Wait a few minutes and query again to see if the correct value appears.

Follow-Up Questions:

What data type are you using to store the tripID?
Can you share the exact query you are using to retrieve the record?
Have you made any recent changes to your Cosmos DB settings or your application code?
Are you using any data synchronization or analytical services like Azure Synapse Link?
How frequently do you encounter this issue, and does it happen with other records as well?

I hope this information helps you identify the issue! If you need further assistance, feel free to provide additional details.

References:

Let me know if you have other questions!

Mahesh Raja Mahalingam 81 Reputation points

2025-12-17T05:01:21.9866667+00:00
Hi Vrishab,

This solution is running there for a very long time (5 years) , we never encounter this before. Its been introduced recently (May be in last 3-5 months) .

Facts:

Not all records are having this issue

The tripID is an integer field and its a Non-hierarchical partition key

We haven't made any recent changes

Yes we are running azure synapse sync (Though we don't need it now, its not possible to disable it)

We are encountering this frequently nowadays, Not happening for all the records but for some other records as well

Questions:

Why we need to change this to integer as cosmos is capable of storing integers. Is there any documentation or cosmos setting suggests that partition key should be string

Converting this field to integer will introduce a massive revamp in the system
Mahesh Raja Mahalingam 81 Reputation points

2025-12-17T05:02:09.4966667+00:00

Forget to thank you for your time, Thank you so much
VRISHABHANATH PATIL 4,825 Reputation points Microsoft External Staff Moderator

2025-12-17T08:50:28.97+00:00
Hi @Mahesh Raja Mahalingam

Thanks for sharing your feedback. Below are a few mitigation steps that should help address your additional questions:

Your system ran fine for years because the tripID values stayed within the safe numeric range. Recently, some tripIDs grew large enough to cross the JSON safe integer limit. Once that happens, Cosmos DB (like any JSON‑based system) begins to round off the number because JSON uses double‑precision floating‑point internally.

That’s why:

Only some records are affected

No code or configuration changes were needed

The issue started in the last few months

Synapse Link has no connection to this behavior

Why this is not a Cosmos DB bug

Cosmos DB fully supports integers—but JSON cannot store very large integers without losing precision. This limitation comes from the IEEE‑754 standard, not from Cosmos DB itself.

As soon as a number exceeds 2^53, precision loss is expected.

Why the tripID should be stored as a string

For partition keys and identifiers like tripIDs, Cosmos best practices recommend using strings, because:

Strings avoid numeric precision issues completely

Strings produce stable hashing for partitions

IDs are rarely used for math, so numeric type offers no benefit

There is no Cosmos setting that can “fix” precision for very large numbers. Storing IDs as strings is the recommended and future‑proof approach.

Impact on your system

You don’t need a big redesign. The migration can be handled safely and gradually:

Start writing new tripIDs as strings

Add a small compatibility check in your read logic

Migrate old documents in batches over time

Keep the partition key name the same—only the value type changes

This avoids any major refactoring or downtime.

Reference - Data Modeling - Azure Cosmos DB for NoSQL | Microsoft Learn
Manoj Kumar Boyini 4,540 Reputation points Microsoft External Staff Moderator

2025-12-26T16:00:23.6566667+00:00

Hi Mahesh Raja Mahalingam,

I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

Share via

Value which I am storing is not returned when I queried the record back

1 answer

Potential Reasons and Solutions:

Steps to Troubleshoot:

Follow-Up Questions:

References:

Your answer