)

Resolves an issue where DAGs using non default value like `weight_rule='absolute'` would fail during
deserialization with `'Unknown priority strategy'` error. The problem occurred
when the scheduler attempted to deserialize tasks that had already been
converted to `PriorityWeightStrategy` instances.

The `validate_and_load_priority_weight_strategy` function now properly handles
cases where a `PriorityWeightStrategy` instance is passed, returning it directly
instead of attempting to re-validate it.

This fix ensures that all weight rule options (`downstream`, `upstream`, `absolute`)
work correctly in the complete DAG processing pipeline including serialization,
storage, and deserialization.

To Reproduce the bug, run the following dag or just run the added unit test without code changes:

```py
from airflow import DAG
from airflow.sdk import task
from airflow.task.weight_rule import WeightRule

with DAG("xcom_backend_dag"):

    @task()
    def xcom_producer():
        return "my_value"

    @task(weight_rule=WeightRule.ABSOLUTE)
    def xcom_consumer(value):
        assert value == "my_value"

    xcom_consumer(xcom_producer())

```

which will then fail, when you try to trigger the dag from UI.

Fix DAG deserialization failure with weight_rule='absolute'

Resolves an issue where DAGs using weight_rule='absolute' would fail during
deserialization with 'Unknown priority strategy' error. The problem occurred
when the SerializedBaseOperator.weight_rule property was re-validating
already-instantiated PriorityWeightStrategy instances.

During deserialization, decode_priority_weight_strategy() creates strategy
instances and stores them in _weight_rule, but the weight_rule property
was calling validate_and_load_priority_weight_strategy() which expected
a string or class, not an instance.

Fixed by checking if _weight_rule is already a PriorityWeightStrategy
instance in the property getter and returning it directly. User input
still goes through proper validation.

This targeted fix resolves the specific deserialization issue while
maintaining existing validation behavior for new operator creation.

(cherry picked from commit aece98b)

…che#55906)

Resolves an issue where DAGs using non default value like `weight_rule='absolute'` would fail during
deserialization with `'Unknown priority strategy'` error. The problem occurred
when the scheduler attempted to deserialize tasks that had already been
converted to `PriorityWeightStrategy` instances.

The `validate_and_load_priority_weight_strategy` function now properly handles
cases where a `PriorityWeightStrategy` instance is passed, returning it directly
instead of attempting to re-validate it.

This fix ensures that all weight rule options (`downstream`, `upstream`, `absolute`)
work correctly in the complete DAG processing pipeline including serialization,
storage, and deserialization.

To Reproduce the bug, run the following dag or just run the added unit test without code changes:

```py
from airflow import DAG
from airflow.sdk import task
from airflow.task.weight_rule import WeightRule

with DAG("xcom_backend_dag"):

    @task()
    def xcom_producer():
        return "my_value"

    @task(weight_rule=WeightRule.ABSOLUTE)
    def xcom_consumer(value):
        assert value == "my_value"

    xcom_consumer(xcom_producer())

```

which will then fail, when you try to trigger the dag from UI.

Fix DAG deserialization failure with weight_rule='absolute'

Resolves an issue where DAGs using weight_rule='absolute' would fail during
deserialization with 'Unknown priority strategy' error. The problem occurred
when the SerializedBaseOperator.weight_rule property was re-validating
already-instantiated PriorityWeightStrategy instances.

During deserialization, decode_priority_weight_strategy() creates strategy
instances and stores them in _weight_rule, but the weight_rule property
was calling validate_and_load_priority_weight_strategy() which expected
a string or class, not an instance.

Fixed by checking if _weight_rule is already a PriorityWeightStrategy
instance in the property getter and returning it directly. User input
still goes through proper validation.

This targeted fix resolves the specific deserialization issue while
maintaining existing validation behavior for new operator creation.