Problem (PECO-3009)
Several E2E tests are skipped on the SEA/REST protocol, attributed to "ADO.NET schema collections not supported / DatabricksConnection-specific casts". Investigation shows this is fixable (mostly test-level), not by-design.
Per-test findings
VerifySchemaTables / VerifySchemaTablesWithNoConstraints (csharp/test/E2E/ClientTests.cs:62-73, skipped on rest, // TODO: PECO-3009): the ADO.NET GetSchema(...) path is generic — it dispatches to connection.GetObjects(...), and SEA implements GetObjects (StatementExecutionConnection.cs:571). No DatabricksConnection cast is involved. Fixable at the data-shape level (SEA's SHOW-command-based GetObjects returning the row/column counts these tests expect). Needs one run to confirm the exact diff.TracePropagationConfigurationTest (csharp/test/E2E/DatabricksConnectionTest.cs:588-615, skipped on rest): fails only on the hard Assert.IsType<DatabricksConnection>(connection) at line 608. Trace propagation is fully wired for SEA (StatementExecutionConnection.cs:267-269, 348). Pure test-only fix — replace with a protocol-agnostic assertion.SetDefaultCatalogAndSchemaOptionsTest (csharp/test/E2E/DatabricksConnectionTest.cs:508-583): already fixed — no skip; uses if (statement is DatabricksStatement …) (line 568) with a SEA else branch. Out of scope (doc is stale here).
Out of scope (legitimately Thrift-only)
Casts to Thrift-only members via the concrete type — DefaultNamespace→TNamespace (DatabricksConnectionTest.cs:499) and TrySetGetDirectResults/DirectResults (line 628, already skipped as "DirectResults is Thrift-only") — are by-design and not part of this issue.
Proposed scope
Re-enable the two VerifySchemaTables* tests on SEA (achieve GetObjects schema-collection parity, or adjust assertions to the documented SEA shape) and fix TracePropagationConfigurationTest to use a protocol-agnostic assertion.
Problem (PECO-3009)
Several E2E tests are skipped on the SEA/REST protocol, attributed to "ADO.NET schema collections not supported / DatabricksConnection-specific casts". Investigation shows this is fixable (mostly test-level), not by-design.
Per-test findings
VerifySchemaTables/VerifySchemaTablesWithNoConstraints(csharp/test/E2E/ClientTests.cs:62-73, skipped onrest,// TODO: PECO-3009): the ADO.NETGetSchema(...)path is generic — it dispatches toconnection.GetObjects(...), and SEA implementsGetObjects(StatementExecutionConnection.cs:571). NoDatabricksConnectioncast is involved. Fixable at the data-shape level (SEA's SHOW-command-basedGetObjectsreturning the row/column counts these tests expect). Needs one run to confirm the exact diff.TracePropagationConfigurationTest(csharp/test/E2E/DatabricksConnectionTest.cs:588-615, skipped onrest): fails only on the hardAssert.IsType<DatabricksConnection>(connection)at line 608. Trace propagation is fully wired for SEA (StatementExecutionConnection.cs:267-269, 348). Pure test-only fix — replace with a protocol-agnostic assertion.SetDefaultCatalogAndSchemaOptionsTest(csharp/test/E2E/DatabricksConnectionTest.cs:508-583): already fixed — no skip; usesif (statement is DatabricksStatement …)(line 568) with a SEAelsebranch. Out of scope (doc is stale here).Out of scope (legitimately Thrift-only)
Casts to Thrift-only members via the concrete type —
DefaultNamespace→TNamespace(DatabricksConnectionTest.cs:499) andTrySetGetDirectResults/DirectResults (line 628, already skipped as "DirectResults is Thrift-only") — are by-design and not part of this issue.Proposed scope
Re-enable the two
VerifySchemaTables*tests on SEA (achieve GetObjects schema-collection parity, or adjust assertions to the documented SEA shape) and fixTracePropagationConfigurationTestto use a protocol-agnostic assertion.