🐛 Bug Report: Appwrite Dashboard -> Invalid max param: Value must be a valid integer & Attribute with the requested ID could not be found

[ivanskodje]

trafficstars

👟 Reproduction steps

When I try to update an document Attribute name (the attribute key from entryCount to contestEntryCount), I get this error on an Integer attribute: Invalid max param: Value must be a valid integer

If I reduce Max to a more realistic value, I get another error when I try to Update: Attribute with the requested ID could not be found.

Both are occurring in the same modal.

Using Appwrite Self-Hosted Version 1.6.0

The Attribute was initially created from code (snippet):

databases.createIntegerAttribute(
        databaseId,
        contestCollectionId,
        "entryCount",
        true,
        0,
      ),

👍 Expected behavior

I expect the Appwrite web GUI to handle this by itself, and not populate nonsensically high integer values by default when opening the Update Attribute window. I also expect Appwrite web GUI to not throw an error when you DO have a valid integer value.

👎 Actual Behavior

🎲 Appwrite version

Version 1.6.x

💻 Operating system

Linux

🧱 Your Environment

Ubuntu Server Self-Hosted Appwrite 1.6.0 Customization: Disabled rate limiting

👀 Have you spent some time to check if this issue has been raised before?

• [x] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• [x] I have read the Code of Conduct

[ivanskodje]

I’m currently looking into this bug.

It appears the root cause is that the backend sends a max 64-bit integer, which exceeds JavaScript’s number precision, leading to rounding errors. number cannot safely handle values above 9007199254740991 due to its 64-bit floating-point format, so numbers like 9223372036854775807 are displayed as 9223372036854776000.

You can confirm this issue with the following test, which highlights the precision loss when handling large values in inputNumber.test.ts:

test('rounds large max value due to JavaScript number precision limits', () => {
    const incorrectMaxValue = '9223372036854776000';
    const jsonData = {
        id: 'input',
        label: 'input',
        // eslint-disable-next-line @typescript-eslint/no-loss-of-precision
        max: 9223372036854775807 
    };

    const { getByLabelText } = render(InputNumber, {
        id: jsonData.id,
        label: jsonData.label,
        max: jsonData.max
    });

    const input = getByLabelText('input');
    const maxAttribute = input.getAttribute('max');
    
    expect(maxAttribute).toBe(incorrectMaxValue);
});

test('renders correct max attribute when large number is provided as a string', () => {
    const correctMaxValue = '9223372036854775807';
    const jsonData = {
        id: 'input',
        label: 'input',
        max: "9223372036854775807" 
    };

    const { getByLabelText } = render(InputNumber, {
        id: jsonData.id,
        label: jsonData.label,
        max: jsonData.max
    });

    const input = getByLabelText('input');
    const maxAttribute = input.getAttribute('max');
    
    expect(maxAttribute).toBe(correctMaxValue);
});

This test should demonstrate that the frontend doesn’t accurately parse the backend’s large max value.

---

The AttributeInteger type in models.d.ts, used in integer.svelte, currently defines min and max as number types:

        /**
         * Minimum value to enforce for new documents.
         */
        min?: number;
        /**
         * Maximum value to enforce for new documents.
         */
        max?: number;

Due to JavaScript’s precision limits, this setup causes immediate inaccuracies when handling large integer values.

Proposed Solutions

I see three possible ways forward:

1. Update models.d.ts to define min and max as string types.
2. Adjust the backend to use a lower max integer value within JavaScript’s safe range.
3. Introduce a BigInt type, though this might be a complex due to BigInt’s incompatibility with JSON serialization.

Request for Feedback

Which approach would be preferred by the Appwrite team? I’m open to other ideas if there’s a simpler solution that fits within existing structures.

[stnguyen90]

@ivanskodje, thanks for raising this issue! 🙏🏼 This is something we did discover internally and were working on fixing it. Thanks for reminding us to circle back on it.