linera-io/linera-protocol · error · async_graphql::Error

count exceeds u32

Error message

count exceeds u32

What it means

The GraphQL schema generated for `SetView` exposes a derived `count` field typed u32, backed by `iterative_count()` (a `usize`). If the set holds more than `u32::MAX` elements the `u32::try_from` fails and the resolver returns 'count exceeds u32'. This is a schema-limit guard for sets beyond ~4.29 billion elements.

Source

Thrown at linera-views/src/views/set_view.rs:1002

    #[async_graphql::Object(cache_control(no_cache), name_type)]
    impl<C, I> SetView<C, I>
    where
        C: Context,
        I: Send + Sync + Serialize + DeserializeOwned + async_graphql::OutputType,
    {
        async fn elements(&self, count: Option<usize>) -> Result<Vec<I>, async_graphql::Error> {
            let mut indices = self.indices().await?;
            if let Some(count) = count {
                indices.truncate(count);
            }
            Ok(indices)
        }

        #[graphql(derived(name = "count"))]
        async fn count_(&self) -> Result<u32, async_graphql::Error> {
            let count = self.iterative_count().await?;
            u32::try_from(count).map_err(|_| async_graphql::Error::new("count exceeds u32"))
        }
    }

    impl<C: Send + Sync, I: async_graphql::OutputType> async_graphql::TypeName for CustomSetView<C, I> {
        fn type_name() -> Cow<'static, str> {
            format!(
                "CustomSetView_{}_{:08x}",
                mangle(I::type_name()),
                hash_name::<I>(),
            )
            .into()
        }
    }

    #[async_graphql::Object(cache_control(no_cache), name_type)]
    impl<C, I> CustomSetView<C, I>
    where
        C: Context,

View on GitHub (pinned to 6c226ddcb3)

Solutions

1. Use `elements(count: n)` to page through the set instead of requesting `count`.
2. Prune or expire set elements so the set stays within representable size.
3. Keep an application-level u64 counter rather than relying on the derived `count`.
4. Ask upstream to widen the field if >2^32 elements is legitimate.

Example fix

# before
query { app { state { participants { count } } } }  # fails past u32::MAX

# after
query { app { state { participants { elements(count: 1000) } } } }  # paginate; maintain participantCount in app state

# sets expose elements(count:) paging
query { app { state { participants { elements(count: 1) } } } }

try { return await gql.query('query { app { state { participants { count } } } }'); } catch (e) { if (/count exceeds u32/i.test(e.message)) { return tallyViaPagedElements('participants'); } throw e; }

When it happens

Trigger: Querying `count` on a SetView accumulated past 4,294,967,295 elements (e.g. a per-transaction membership set that is never pruned).

Common situations: Unbounded set growth in long-running applications; synthetic tests filling a set past the u32 boundary.

Related errors

• count exceeds u32
• count exceeds u32
• count exceeds u32
• Query {argument:?} is invalid and could not be deserialized
• Attempt to modify storage from a service

AI-assisted analysis of linera-io/linera-protocol@6c226ddcb3 (2026-08-22). Data as JSON: /api/errors/ed73109c088e884a. Report an issue: GitHub.