Add event_id field to Event base class

[GauthamGoli]

No description provided.

[kracekumar]

Opinion: Consider using default_factory=uuid.uuid4. More: https://docs.python.org/3/library/dataclasses.html#dataclasses.field and you can convert to string while sending.

[kracekumar]

Opinion: I feel id is better name. Consider readability for event.id vs event.event_id

[sidmitra]

I would be fine with id going forward. But not that adding this might cause other issues in existing events where id is used.

https://github.com/airbase/airbase-backend/blob/master/airbase_platform/receivers.py#L69-L70

I would assume the child classes can anyway override the base class definition? So we can figure out a transition for existing use cases if we need to do this.

cc @gman90 since @Airbase/vault will be one of the core users of kafka .

We can also get on a periodic call if needed, until we iron out some basics. I think there are a bunch of people that are starting out this quarter on the eventbus, and i've noticed some issues(which might or might not be something important).

[GauthamGoli]

So we can figure out a transition for existing use cases if we need to do this.

For https://github.com/airbase/airbase-backend/blob/master/airbase_platform/receivers.py#L69-L70
Either

1. Introduce a v2 event OR
2. Add an additional state_id field (to replace idusage) at producer and add logic within consumer to handle this

---

Edit:
Taking a closer look, we'll have to use both the above approaches sequentially.
Attempting to move id field from subclasses to base Event class is unique case and different from any event migrations that we might see in future, this particular migration has to be done in 3 phases

1. Introduce v2 event(s) with existing id field renamed, Implement V2 consumers
2. Once existing V1 events are all consumed, Remove V1 events, v1 topics
3. Refactor event_id to id in Base classes, update consumers and producers

[sidmitra]

@GauthamGoli Anything is fine, as long as you ensure the existing topics don't break(or there's a workaround to fix issues)

[gman90]

The main thing about changing the base class id field is what happens to inflight events. At this point, the event class is the schema so changing that will cause an issue for inflight events. We are going to have to think about mirgrations

[GauthamGoli]

After discussion with @sidmitra and @gman90 we'd decided to go forward with event_id field to avoid refactor and migration effort.

I've however updated Event base class to update type of event_id to uuid.UUID

[sidmitra]

Merging this means this will automatically go live on production; because in pyproject.toml on backend we only specify branch.

eventbusk = {git = "https://github.com/Airbase/eventbusk.git", rev = "main"}

Maybe we should first specify a commit or tag and increase the existing version first and specify that on the backend. We don't want automatic upgrades but explicit/manual ones.

@GauthamGoli

[GauthamGoli]

@sidmitra Agree with tagging releases, should we tag existing code in main as semantic version 1.0.0 ?

[sidmitra]

@GauthamGoli

@sidmitra Agree with tagging releases, should we tag existing code in main as semantic version 1.0.0 ?

The current version is here:
https://github.com/Airbase/eventbusk/blob/main/pyproject.toml#L3
Feel free to update a minor version. 0.2.0 since it's mostly backward compatible. We can follow semver.

[GauthamGoli]

Had to use setattr here instead because event_id field has default_factory=uuid.uuid4, init=False
and to keep things backwards compatible event_id will be set as None for older events