Skip to content

Pass the whole Dispatch object when reporting dispatch updates #55

@llucax

Description

@llucax

We are now using a DispatchUpdate object that only has the selector (named as components), dry_run and payload (maybe named inputs or options).

It might be better to send an actual Dispatch object, in case the user needs to access more information about the particular dispatch that triggered the update.

We still need to account for potential "merges", like for now dispatches with the same type as merged is if they were one big virtual dispatch. For example, if we are merging all dispatches with different IDs but the same type, and we have id=1 start=10:00 end=11:00 and id=2 start=11:00 end=None, that would be merged into a dispatch with start=10:00 and end=None).

Related to:

If we do no merging by default, then we can just return the Dispatch object and other merge functions can have their own update types that make sense for that particular merge. For example, if we are merging by selector as well as type, we might not want to have the selector in the DispatchUpdate as it is redundant.

Originally posted by @llucax in #54 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    scope:breaking-changeBreaking change, users will need to update their codetype:enhancementNew feature or enhancement visitble to users

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions