Bug: Error: Number too big to be encoded when upsert'ing records

[yvesk]

Describe the bug

Storing a large negative float produces records that cannot be read.

Maybe related/duplicate of surrealdb/surrealdb#3828

Steps to reproduce

DEFINE TABLE test;
UPSERT test:1 CONTENT { "floatValue": -3.4028235E38 };
SELECT * FROM test:1;

Result:
-------- Query 1 (414.667µs) --------

"The table 'test' already exists"

-------- Query 2 (152.25µs) --------

"Error: Number too big to be encoded"

-------- Query 3 (24.917µs) --------

"Error: Number too big to be encoded"

Expected behaviour

The select query should return the record

SurrealDB version

surreal 2.1.4 for macos on aarch64 surrealkv storage

Contact Details

[email protected]

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[DelSkayn]

I am unable to replicate this bug on linux, maybe an issue with mac?

Could you provide more details about how you ran the query? Was it run via the CLI, or some other way?
I see that the first query returns the result that happens when a table is already present could you try to run it in a clean DB and see if the same error still happens?

[yvesk]

Surreal started on MacBook pro M1 with new DB

$ surreal start -A --user root --pass root surrealkv://test.db

 .d8888b.                                             888 8888888b.  888888b.
d88P  Y88b                                            888 888  'Y88b 888  '88b
Y88b.                                                 888 888    888 888  .88P
 'Y888b.   888  888 888d888 888d888  .d88b.   8888b.  888 888    888 8888888K.
    'Y88b. 888  888 888P'   888P'   d8P  Y8b     '88b 888 888    888 888  'Y88b
      '888 888  888 888     888     88888888 .d888888 888 888    888 888    888
Y88b  d88P Y88b 888 888     888     Y8b.     888  888 888 888  .d88P 888   d88P
 'Y8888P'   'Y88888 888     888      'Y8888  'Y888888 888 8888888P'  8888888P'


2025-01-16T13:18:06.122890Z  INFO surreal::env: Running 2.1.4 for macos on aarch64
2025-01-16T13:18:06.122943Z  INFO surrealdb::core::kvs::ds: Starting kvs store at surrealkv://test.db
2025-01-16T13:18:06.145869Z  INFO surrealdb::core::kvs::ds: Started kvs store at test.db with versions disabled
2025-01-16T13:18:06.146638Z  INFO surrealdb::core::kvs::ds: Credentials were provided, and no root users were found. The root user 'root' will be created
2025-01-16T13:18:06.184331Z  INFO surrealdb::net: Listening for a system shutdown signal.
2025-01-16T13:18:06.184329Z  INFO surrealdb::net: Started web server on 127.0.0.1:8000

Client to run query: Surrealist Version 3.1.9 (20241224.191641) (on same M1 Mac)

USE NAMESPACE test;
USE DATABASE test;

DEFINE TABLE test;
UPSERT test:1 CONTENT { "floatValue": -3.4028235E38 };
SELECT * FROM test:1; 

Result
-------- Query 1 (22.042µs) --------

NONE

-------- Query 2 (2.583µs) --------

NONE

-------- Query 3 (898.709µs) --------

NONE

-------- Query 4 (388µs) --------

"Error: Number too big to be encoded"

-------- Query 5 (59.625µs) --------

"Error: Number too big to be encoded"

[yvesk]

Ran the same query on Surreal Cloud. Exactly the same result:

[DelSkayn]

This seems to be a bug in surrealist, as far as I am able to tell surrealdb sends the right response, it is probably not properly handled on surrealist side.

[DelSkayn]

The bug only happens in surrealist, in the CLI it seems to be fine, surrealdb also seems to respond with the right response. Can it be a bug in surrealist handling of CBOR deserialization?

[yvesk]

Yes, it seems to be in Surrealist. I cannot reproduce the issue in the CLI.

% surreal sql -u root -p root

#
#  Welcome to the SurrealDB SQL shell
#
#  How to use this shell:
#    - Different statements within a query should be separated by a (;) semicolon.
#    - To create a multi-line query, end your lines with a (\) backslash, and press enter.
#    - To exit, send a SIGTERM or press CTRL+C
#
#  Consult https://surrealdb.com/docs/cli/sql for further instructions
#
#  SurrealDB version: 2.1.4
#

> USE NAMESPACE test;
USE DATABASE test;

DEFINE TABLE test;
UPSERT test:1 CONTENT { "floatValue": -3.4028235E38 };
SELECT * FROM test:1;
[NONE, NONE, NONE, [{ floatValue: -340282350000000000000000000000000000000f, id: test:1 }], [{ floatValue: -340282350000000000000000000000000000000f, id: test:1 }]]

test/test>