TRFC-3: Component capabilities

[s3rius]

Currently, we have a short paragraph about the conventions that brokers support in the documentation.

We'd like to standardize this by introducing a Capabilities enum in the base taskiq package.

I propose defining an enum for each pluggable component, including:

• Broker
• ResultBackend
• ScheduleSource

Each component will have a ClassVar listing its supported capabilities. For every component, there will be a corresponding enum that defines all possible capabilities.

For example:

class BrokerCapabilities(StrEnum):
    DELAY = "x-taskiq-b-delay"
    PRIORITY = "x-taskiq-b-priority"

class ResultBackendCapabilities(StrEnum):
    GET_PROGRESS = "x-taskiq-rb-get-progress"

class ScheduleSourceCapabilities(StrEnum):
    ADD_SCHEDULE = "x-taskiq-ss-add-schedule"

With this approach, the library can warn users about unsupported actions, making it safer and more consistent to work with label-based capabilities.

[danfimov]

What will be the default behavior for older versions of libraries that were released before this proposal?

I am confused by the following case:

• The author of the taskiq-ydb library (for example) did not lock the taskiq version in dependencies (for example taskiq>=0.11.16 in pyproject.toml) and implemented priority without adding the corresponding ClassVar;
• The end user uses taskiq-ydb and priority feature in his project;
• The user decides to update dependencies (uv lock --upgrade for example). He receives a new version of taskiq, which will start to look at ClassVar;
• As a result: user has warning priority not implemented in this broker (I guess?). It is not clear to the user what went wrong.