Skip to content

Spec dotnet test pipe protocol #6187

@Youssef1313

Description

@Youssef1313

To help with clarity on implementation on dotnet test side, we want to write a spec, ideally very soon, before .NET 10 is GA, so we can revise the implementation on SDK and closely follow a well-defined specification.

We also need to explicitly state what behaviors are allowed, what is not allowed, and explicitly throw exception in .NET SDK implementation if a protocol violation is hit.

I think the current implementation on .NET SDK assumes that the "server" (test app, MTP implementation) is correct.

For example:

  • The spec should mention that multiple handshakes from the same test app is allowed (in case of retry, in case of sharding)
    • What fields of the handshake message are expected to be the same, and what fields may be different?
    • Implementation on SDK should explicitly throw if a second handshake has a different value of a field that was expected to be the same (e.g, TFM?, Architecture?, ExecutionId?, TargetPath?)
  • Handshaking:
    • Today, both dotnet test and MTP use the same HandshakeMessage. The HandshakeMessage contain process id, architecture, framework, OS, supported protocol version. Why do we ever care about the process id of the dotnet? or its architecture or target framework? Is it a flaw in the protocol design?
    • What if the test app doesn't handshake at all? Today, I think we accept it and will consider it passing. That's very wrong IMO. EDIT: This point is fixed in SDK now.

Above are just examples of when having a spec will help.

Metadata

Metadata

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions