Problem
PHP SDK 2.0.0-rc.30 rejects a non-Avro codec passed to the Client constructor, but public low-level send surfaces still bypass that boundary. Client::updateSchedule() forwards caller-supplied schedule changes unchanged, including a schedule action input envelope tagged codec: "json". Client::completeWorkflowTask() likewise forwards caller-supplied command payload envelopes unchanged. Both requests reach the transport instead of failing locally with unsupported_payload_codec.
This contradicts the public Avro-only contract and the release claim that non-Avro configuration fails before transmission. Server-side rejection remains necessary, but it does not make the SDK boundary complete.
Acceptance criteria
- Enforce the fixed Avro Value schema and single-object framing at every public PHP Client send path that can accept a caller-supplied durable payload or payload envelope.
- Cover schedule-update action inputs and low-level workflow-task completion command payloads, including JSON-tagged, unknown-codec, untagged/raw JSON, and falsely Avro-tagged non-Avro bytes.
- Reject unsupported payloads with the stable actionable
unsupported_payload_codec diagnostic before Transport::send() is invoked.
- Validate only schema-defined payload locations. Memo, search attributes, failure details, and other user-owned metadata containing keys such as
codec, payload_codec, or blob must not be mistaken for payload envelopes.
- Preserve valid Avro schedule updates and workflow commands, and preserve the managed Worker path that already emits Avro.
- Add focused transport-spy regressions proving rejected inputs produce zero requests, valid Avro inputs are sent, and codec-looking user metadata is preserved.
Complete when
Every public PHP SDK path that can send a durable payload either creates it with AvroPayloadCodec or validates it at its schema-defined boundary before transport, with regressions preventing low-level pass-through APIs from reintroducing JSON or unknown codecs.
Problem
PHP SDK 2.0.0-rc.30 rejects a non-Avro codec passed to the Client constructor, but public low-level send surfaces still bypass that boundary.
Client::updateSchedule()forwards caller-supplied schedule changes unchanged, including a schedule action input envelope taggedcodec: "json".Client::completeWorkflowTask()likewise forwards caller-supplied command payload envelopes unchanged. Both requests reach the transport instead of failing locally withunsupported_payload_codec.This contradicts the public Avro-only contract and the release claim that non-Avro configuration fails before transmission. Server-side rejection remains necessary, but it does not make the SDK boundary complete.
Acceptance criteria
unsupported_payload_codecdiagnostic beforeTransport::send()is invoked.codec,payload_codec, orblobmust not be mistaken for payload envelopes.Complete when
Every public PHP SDK path that can send a durable payload either creates it with
AvroPayloadCodecor validates it at its schema-defined boundary before transport, with regressions preventing low-level pass-through APIs from reintroducing JSON or unknown codecs.