Sadly https://github.com/SeaQL/sea-query will silently use signed integers for Postgres even when the schema written as code calls for them to be unsigned 🤮
Similar deal for bigints, etc. Interestingly we originally chose chain_id to be a big int, but the domain ID to be an int..
explorer4=> \d domain
Table "public.domain"
Column | Type | Collation | Nullable | Default
---------------+-----------------------------+-----------+----------+----------------------------------------------------------
id | integer | | not null |
time_created | timestamp without time zone | | not null | '2023-10-06 23:47:05.28212'::timestamp without time zone
time_updated | timestamp without time zone | | not null |
name | text | | not null |
native_token | text | | not null |
chain_id | bigint | | |
is_test_net | boolean | | not null |
is_deprecated | boolean | | not null |
The impact of this is we can't add domains like ancient8testnet whose domain ID is greater than (2^31) - 1 to the scraper.
We should probably:
spot everywhere we rely on unsigned integer types and find out if this poses any other issues for us
possibly move to larger data types to account for this deficiency
Maybe good to do this at the same time as considering how we'll get alt execution envs to work, as that'll probably require a schema change anyways
Sadly https://github.com/SeaQL/sea-query will silently use signed integers for Postgres even when the schema written as code calls for them to be unsigned 🤮
This means that e.g. the domain ID, which supposed to be an unsigned 32 bit integer: https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/8ccfdb7f0119ce28ceaef4fbcfc05bafec97225a/rust/agents/scraper/migration/src/m20230309_000001_create_table_domain.rs#L248 will actually be an
integer
, which is signed ðŸ˜Similar deal for bigints, etc. Interestingly we originally chose
chain_id
to be a big int, but the domain ID to be an int..The impact of this is we can't add domains like
ancient8testnet
whose domain ID is greater than(2^31) - 1
to the scraper.We should probably:
Maybe good to do this at the same time as considering how we'll get alt execution envs to work, as that'll probably require a schema change anyways