Data Connect emulator crashes when using `uuidV4()`

[ciriousjoker]

Environment info

firebase-tools: 14.27.0

Platform: macOS

Test case

type SomeTable @table(name: "test", key: ["id"]) {
  id: UUID! @default(expr: "uuidV4()")
  data: String!
}

mutation InsertExerciseRecord(
  $data: String!
) @auth(level: NO_ACCESS) {
  someTable_insert(
    data: {
      data: $data
    }
  )
}

Steps to reproduce

Generate this schema and try to insert data. It fails and the emulator crashes.

Expected behavior

Should autogenerate the id field.

Actual behavior

Emulator crashes.

[aalej]

Hey @ciriousjoker, thanks for providing a test case. I'm unable to reproduce the issue. When running the sample mutation provided, it performs the insert without any errors. Here's my MCVE, let me know in case I missed anything here.

Could you try updating to the latest version of firebase-tools, which is currently v15.5.1? If you are still encountering the issue even after updating, could you share the contents of your dataconnect-debug.log and firebase-debug.log so that we can check what caused the emulator to crash. Please remove any PIIs before sharing the contents.

[ciriousjoker]

Thanks for the effort to reproduce this!
After reporting #9857, I realized that I used an outdated version, but this issue was still reproducible, so I didn't close it.

I now realized though that the repro example is slightly different, because when trying out different ways of getting the uuid to work I ended up with this version instead, which still breaks on v15.5.1:

type ReproUuidExpr @table(name: "repro_uuid_exprs", key: ["id"]) {
  id: UUID!
  label: String!
}

mutation {
  reproUuidExpr_insert(
    data: {
      id_expr: "uuidV4()"
      label: "repro-uuid-expr"
    }
  )
}

The difference is that specifying the uuid in the mutation itself still fails.

Note that I'm not sure if this way of doing it is 100% intended/supported. I was under the impression that https://firebase.blog/posts/2025/06/dataconnect-server-values meant that I could use "expressions" there and I hoped that uuid() counts as one.

That being said, the default expression works for our usecase in practice so I'm going to use that.

[ciriousjoker]

@aalej I've provided the feedback. Is this still an issue or should this be closed?

[aalej]

sorry for the late revert. It's good to know that you were able to workaround this by using @default(expr: "uuidV4()"). Checking the new sample, I think that expression should work. Tried it on production and it runs without any issues, so it seems like this is an issue with the emulators. Let me raise this to our engineering team.

Sharing the updated MCVE here

[ciriousjoker]

@aalej This issue still has "needs author feedback". Can this label be removed or is there anything I should do/answer?

[aalej]

Removing the label, the current information is sufficient. Thanks again @ciriousjoker!