Once you have the other stuff from dev you can use the Newtype pattern for the ID :D

Do we want an index on event(aggregate_id, seq)?

I almost did that! well, not an explicit index, but a constraint saying that the combo of (aggregate_id, seq) was always unique to ensure we don't insert duplicate events (or make sure sequences aren't messed up).

An index can make writes slower, and consumes more memory, so I decided to wait until we understand the tradeoffs here better. We will be querying the latest events for an aggregate quite a bit so an index probably makes sense, but want to measure it first

Should this use immediateTransaction as well?

It's not as important here because we aren't generating sequence ids. The main role of this is to check to make sure we've already seen all the events before it; once we've checked that, it doesn't matter what else happens in the system, the same event could even be recorded multiple times and we would just ignore any writes after the first one

This function is the weakest part of the system though and I need to rewrite it. It needs to do a lot more, such as handle an array of sequential events, validating their seq ids, filtering out any that we've already seen, and writing own the new ones all at once. I'm not sure we need immediate, maybe we do, need to think through all of that more

Should we also use the versioned name here?

AI ELABORATION

1. SyncEvent.define(...) returns this object:

{
  type: "session.updated",
  version: "v1",
  ...
}

That object gets stored as Session.Event.Updated.

2. A subscriber does:

Bus.subscribe(Session.Event.Updated, cb)

Bus.subscribe uses def.type directly, so it subscribes to "session.updated".

3. Later, SyncEvent.run(Session.Event.Updated, data) runs. Inside run(), it does this:

const versionedDef = { ...def, type: versionedName(def.type, def.version) }
Bus.publish(versionedDef, ...)

So it does not publish the original object. It creates a new object with type: "session.updated.v1".

4. Bus.publish(...) sends the event to listeners for that exact string: "session.updated.v1". But the subscriber was listening on "session.updated". So it never fires.

Yeah, this is a good catch, I think that will fail. I hadn't tested listening for individual events as that won't usually happen, you'll just stream in all of the events and record them. That said, this should work, and I should probably rethink this overall.

I've done a couple iterations of this, and we don't use the version field much anyway, so maybe we should merge the version into the name at the start (with a format like session.updated/v1 or something) and just forget about storing it as a separate field