What to do on failed or blocked event insertions?
Bug #495179 reported by
Mikkel Kamstrup Erlandsen
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Zeitgeist Framework |
Fix Released
|
Critical
|
Markus Korn |
Bug Description
This bug is filed in relation to bug #495017: "AttributeError: 'NoneType' object has no attribute 'payload'"
Markus asks what to do with failed or blocked events in InsertEvents(). This is an important questions since we can't not raise an error or simply leave the event id out of the response. Clients depend on mapping the returned event_ids->events.
I propose to say that event id 0, indicates an error. I think this is a nice solution: easy to implement without breaking API, and easy to handle for clients because a boolean test "if not event_id : print 'eeeeeek!'" works.
Changed in zeitgeist: | |
milestone: | none → 0.3.1 |
importance: | Undecided → Critical |
status: | New → Confirmed |
Changed in zeitgeist: | |
status: | Confirmed → Fix Committed |
Changed in zeitgeist: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
I like this solution more than my proposal in my comment on the other bugreport. But I still think it is not optimal because there is no reason to distinguish between different reason of failure. The client will always get the same result back no matter if this event was blocked by an extension, blocked because the event already had an id, blocked because the client tried to add an event without a subject, and so on.
Is it possible to send negative integers over dbus, so we can define
v >= 0 -> id of an event
v < 0 -> error
We also predefine some error values as constants.