Capella WebUI Bug - Data Corruption for Large Integers

Summary

Capella’s WebUI can lead to database corruption when dealing with extremely large 64-bit Integers because the editing popover incorrectly rounds the value such that it becomes an overflow. Reference the included screenshot.

Steps to Reproduce

  1. After setting up sync, I used the Swift SDK to save a MutableDocument containing a property with an Int value of 9,223,372,036,854,775,807. That’s 2^63 - 1, which is the largest possible 64-bit Integer.

  2. I went to the Capella web UI, edited the document, and surprisingly saw this value in the editing UI: 9223372036854776000. This is an overflow. It’s 193 larger than the largest possible 64-bit Integer because it has been rounded up and has dropped precision.

  3. The ACTUAL value stored in the database is still 2^63 - 1 and the "table of documents” behind the editing popover shows that correctly. It’s only the editing popover that has an incorrect, rounded value.

  4. Here’s the dangerous part: If I edit this number on the web interface, I can corrupt the value. Change the leading 9 to an 8 and the database ends up storing this number: 8,223,372,036,854,776,000. That’s wrong. It SHOULD be storing 8,223,372,036,854,775,807. The incorrect value syncs down to my local device, propagating the erroneous rounding from the editing popover.

  5. Also dangerous: If I launch the editing interface on Capella’s web UI but I don’t actually change the number (say I edit a different property) and then click “save”, the numerical value stored in the database is still 2^63 - 1. This means that, for large integers, what you see in the editing UI may not be the actual value that’s in the database when you save the document. You THINK you’re storing the number you see in that editing popover, but you’re actually storing a different one.

Jira

I looked through the projects in Jira, but did not find one for the Capella web interface. I figured I’d post the bug here so someone can put it in the right spot.

It’s a known limitation. As I recall it’s due to the largest number that can be represented in Javascript. Workaround is to store it as as String.

Yep. That’s precisely (see what I did there?) the cause. JavaScript’s native number handling has only 53 bits of precision. But notice that the “documents table” behind the editing popover has the correct value. It’s just the editing popover that is wrong.

There are also ways to deal with this problem in modern JavaScript. Specifically BigInt from ECMAScript 2020. The Capella webUI needs to modernize—the Couchbase mobile SDKs offer the ability to store 64-bit Integers so the Capella webUI needs to handle that. It’s not reasonable to say, “Actually, don’t store anything above 2^53 - 1 because JavaScript is dumb and those values might be corrupted if you use the Capella website.”

You can open a ticket from the Capella UI. For free tier I think it’s Leave Feedback. For licensed, I think it’s under “Request Support”. It has more weight coming from a customer.

1 Like