Dynamic workflows, activities, signals, and queries

[cretz]

What was changed

• Add a temporalio.common.RawValue class which represents a raw payload that is never converted (but still encoded/decoded)
• Update composite/default payload converter to pass through that type by default
• Add dynamic=True for @workflow.defn which requires the run method to accept a single Sequence[RawValue] param
• Add dynamic=True for @activity.defn which requires the function to accept a single Sequence[RawValue] param
• Updated @workflow.signal to work with Sequence[RawValue] args and deprecate/warn when using the existing style (which was varargs of already-converted values which makes little sense)
• Updated @workflow.update to work with Sequence[RawValue] args and deprecate/warn when using the existing style (which was varargs of already-converted values which makes little sense)
• 💥 Interceptor behavior change! We now resolve signal and query handlers before invoking interceptors like all other SDKs. If a user had some advanced use case where they had a custom interceptor and expected it to be called even for unknown signals/queries, it now will not. This should be rare.

Checklist

1. Closes [Feature Request] Support dynamic workflows, activities, signals, and queries #242

[Sushisource]

Looks good to me, but I do think it'd probably make sense to pass the name as the first arg to dynamic workflows/activities?

[Sushisource]

Seems like we'd want name argument? (To the workflow input)

[cretz]

We surface this via contextual workflow info, so I intentionally leave it off here (same as .NET)

[Sushisource]

Same, is this also missing name?

[cretz]

We surface this via contextual activity info, so I intentionally leave it off here (same as .NET)

[Sushisource]

This doesn't appear to actually be enforced, just ignored. Would be nice to actually enforce (or better, make unrepresentable if reasonable)

[cretz]

It is unrepresentable with the overloads if you use a type checker which everyone should. Right now, name is just ignored when dynamic is present. If we want a runtime check, I can add it.

[Sushisource]

IMO for this & signal it'd be better to use some special sigil type to represent the dynamic handler rather than just None.

[cretz]

We have used None to represent dynamic for signals/queries for a long time now. Not sure it's worth changing.

[dandavison]

This is just code golf but FWIW this function has probably gained enough complexity now that it would be more readable as a generator:

        return list(self._payloads(values))

    def _payloads(
        self, values Sequence[Any]
    ) -> Generator[temporalio.api.common.v1.Payload]:
        for index, value in enumerate(values):
            # We intentionally attempt these serially just in case a stateful
            # converter may rely on the previous values
            # RawValue should just pass through
            if isinstance(value, temporalio.common.RawValue):
                yield value.payload
                continue
            else:
                for converter in self.converters.values():
                    payload = converter.to_payload(value)
                    if payload is not None:
                        yield payload
                        continue
            raise RuntimeError(
                f"Value at index {index} of type {type(value)} has no known converter"
            )

[cretz]

Not sure this small function deserves to be delegated to another small function. I don't think it's that complicated. Also, your second continue needs to be a break.

[cretz]

Builds are intermittently (but often) failing with python/cpython#91351 on Windows that surfaces because our sandbox importlib. This seems to be very specific to pytest runs and warnings capturing. Based on others' research there, we may disable warnings capture for pytest on Windows.

Looking at linked issues on the one linked above, it seems at least for now disabling Python bytecode during Windows tests fixes it. This is a pytest only deal, so users are not affected.