task_type should be respected as it is supposed to be overridden.

[suiting-young]

class BaseOperator(...):
    @property
    def task_type(self) -> str: ...

The task_type property is designed to show customized name (for human to distinguish, not to import code)
and is allowed to override in sub-class, if I understand correctly.

---

My Use Case

I need to distinguish operators by connection type, something likes:

from airflow.providers.jdbc.operators.jdbc import JdbcOperator

class DistinctJdbcOperator(JdbcOperator):
    @property
    def task_type(self):
        return self.conn.conn_type.capitalize() + 'JdbcOperator'

---

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.

[kaxil]

No, we use task_type to get the class name itself and was not intended to have a Human Readable name.

We also use it here for validation:

airflow/airflow/serialization/serialized_objects.py

Lines 434 to 440 in 0e13458

	for ope in plugins_manager.operator_extra_links:
	for operator in ope.operators:
	if (
	operator.__name__ == encoded_op["_task_type"]
	and operator.__module__ == encoded_op["_task_module"]
	):
	op_extra_links_from_plugin.update({ope.name: ope})

[suiting-young]

was not intended to have a Human Readable name.

My use case isn't to place arbitrary sentences there, but create some fake-sub-classes (that my users will treat them as real class names).

In 21a91c4 (2nd commit) I extended BaseOperatorLink.operators to accept str.
So that task_type-customized classes can have their own links.

This won't affect existing code because

• No operator overrode task_type in official source tree.
• Custom installation has no reason (and actually, no effect) to override task_type without 328a43a (1st commit).

[github-actions]

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

[github-actions]

The Workflow run is cancelling this PR. It has some failed jobs matching ^Pylint$,^Static checks,^Build docs$,^Spell check docs$,^Backport packages$,^Provider packages,^Checks: Helm tests$,^Test OpenAPI*.

[ashb]

Please find a cleaner way of writing this -- it is hard/impossible to grok what it is going.

[suiting-young]

Extracted this part to a function in 1fde244.

[ashb]

Code comments aside, I'm not sure if we want to support this behaviour - I'm trying to think through future implications where we might use the serialized representation for more (such as in the worker for actually creating Operator objects), and enabling this PR might stop us doing that.

[suiting-young]

might use the serialized representation for more (such as in the worker for actually creating Operator objects)

Do you mean

• serialize the whole operator (e.g. through pickle),
• or only serialize import path, and arguments of constructor?

And either way, execute the deserialized operator without its DAG?

[ashb]

I'm not thinking pickle, no, so something closer to the second point.

[ashb]

Closing this for now as won't fix, sorry.