Unique constraint violation in init causes unhelpful error generating bindings

[PastelStoic]

It took a while to hunt down the source of this. Rather than an error message, trying to generate bindings gave me the unhelpful message EOF while parsing a value at line 1 column 0 with no other details. I resorted to rolling back one commit at a time, then deleting individual lines until I found the part where the error occurred.

To reproduce: create a table with a unique column, then use table.insert to make two entries with duplicate keys. Not a bug, but the error message indicates a parsing error rather than a module runtime error.

I suggest adding help info to the bindings command when this happens, saying that one or more reducers experienced a fatal error.

[bfops]

Hey @PastelStoic, would you be able to provide an example of the module that causes the error?

Generating bindings (via spacetime generate) doesn't connect to the database or server at all. It's just parsing the source code, so the error is unrelated to the state of the database or what has/hasn't been inserted. (You should be able to run spacetime generate without even being connected to the internet).

[PastelStoic]

Here's a minimal reproduction of the problem code:

use spacetimedb::{table, Identity, ReducerContext, Table};

pub(crate) static SPACETIME_AUTH_ISS: &str = "https://auth.spacetimedb.com/oidc";

#[table(name = usertable, public)]
pub struct User {
    #[auto_inc]
    #[primary_key]
    pub id: u32,
    #[unique]
    pub identity: Identity,
}

#[spacetimedb::reducer(init)]
pub fn init(ctx: &ReducerContext) -> Result<(), String> {
    ctx.db
        .usertable()
        .try_insert(User {
            id: 0,
            identity: Identity::from_claims(SPACETIME_AUTH_ISS, "user_5h2tJayfCDRlgQPbB0Ijpl"),
        })
        .map_err(|e| format!("Violated unique constraint for user table: {e}"))?;
    ctx.db
        .usertable()
        .try_insert(User {
            id: 0,
            identity: Identity::from_claims(SPACETIME_AUTH_ISS, "user_5h2tJayfCDRlgQPbB0Ijpl"),
        })
        .map_err(|e| format!("Violated unique constraint for user table: {e}"))?;
    Ok(())
}

I'm running spacetime generate --lang typescript and getting the following error:

Error: could not extract schema

Caused by:
    EOF while parsing a value at line 1 column 0

Changing a single letter in one of the identity fields removes the error.

This was in a freshly-generated (spacetime init) module, on spacetime 1.6.0.

[bfops]

Thank you for the module! You're right, spacetime generate does rely on what's generated by spacetime init. I didn't read your message closely enough, sorry about the bad info.

Do you also see this line in your output?

Error: Violated unique constraint for user table: insertion error on table `usertable`:duplicate unique column

We'll look into improving the error communication here.

[bfops]

Reduced repro for the team:

use spacetimedb::{table, ReducerContext, Table};

#[table(name=user, public)]
pub struct User {
    #[unique]
    pub id: u32,
    pub other: u32,
}

#[spacetimedb::reducer(init)]
pub fn init(ctx: &ReducerContext) -> Result<(), String> {
    ctx.db.user().try_insert(User { id: 0, other: 0 })?;
    ctx.db.user().try_insert(User { id: 0, other: 1 })?;
    Ok(())
}

Run spacetime generate with any lang and output dir.

[PastelStoic]

Thank you for the module! You're right, spacetime generate does rely on what's generated by spacetime init. I didn't read your message closely enough, sorry about the bad info.

Do you also see this line in your output?

Error: Violated unique constraint for user table: insertion error on table `usertable`:duplicate unique column

We'll look into improving the error communication here.

No, I pasted everything I got in the error, as far as I recall.

[cloutiertyler]

Update here, we discussed this and we should just not be calling the init reducer during generate at all.

[bfops]

^ what Tyler said. (But also, it's worth saying that if init fails, it will fail when you publish the module).

[PastelStoic]

Update here, we discussed this and we should just not be calling the init reducer during generate at all.

I didn't want to make a bug report, but having an identity-level connection validation means that generate fails, because it can't connect to the module. I couldn't figure out why, but I assume this is the cause.