[junkmd]

Motivation

Arrays of records (VT_ARRAY | VT_RECORD) are only partially supported by comtypes today.
Through a typed (vtable) interface, record arrays go in and come out correctly.
Through IDispatch::Invovke, they can be sent to a server as typed SAFEARRAYs, but a record array coming back fails with KeyError: 36 (#63; #104 proposes unpacking them).

What is missing is not only the fix, but a way to know whether any change in this area is correct.
A fix for #63 touches the code that unpacks record arrays, and that code is shared with the vtable path, which works today.
Without a baseline, a change can look right on the path it targets while silently regressing the other one.
It is also hard to test against existing COM components: nothing predictable accepts and returns record arrays with known contents.

This PR adds that baseline before touching any library code, for three reasons:

• Tell intended behavior from known limitations.
  Some assertRaises cases are intended (e.g., the server rejects empty arrays with E_INVALIDARG). Others document a known limitation (VARIANT._get_value cannot unpack arrays of arbitrary type #63) and are marked CHARACTERIZATION(#63).
• Make a future fix visible.
  The CHARACTERIZATION(#63) marker is set in the msg argument of assertRaises, so it appears only when the call stops raising exceptions (i.e., when VARIANT._get_value cannot unpack arrays of arbitrary type #63 is fixed). When someone fixes VARIANT._get_value cannot unpack arrays of arbitrary type #63, this failure will remind them to update the test to a normal test case.
• Make expected values obvious.
  The server method returns the input array in reverse, so the expected value is simply reversed(records). Using arrays with multiple elements also reveals issues that single-element arrays would conceal.

Two record kinds are tested on purpose. Integer-only records isolate marshaling. BSTR records add ownership of heap-allocated strings, which is where unpacking changes are most likely to go wrong.

Summary

• One out-of-process COM server component serves both IDualRecordSafearrayTest (vtable) and IDispRecordSafearrayTest (dispatch).
• The same scenarios run over both paths through a mixin, so a difference between the paths appears as a difference in assertions.

What this does not do:

• It does not change production code.

Related: #63, #104. This does not close either.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 99.09091% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.76%. Comparing base (2b4e5f1) to head (38bfe8d).

Files with missing lines	Patch %	Lines
comtypes/test/test_record_safearray_bstr.py	99.10%	2 Missing ⚠️
comtypes/test/test_record_safearray_value.py	99.07%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #980      +/-   ##
==========================================
+ Coverage   90.50%   90.76%   +0.26%     
==========================================
  Files         145      147       +2     
  Lines       14831    15271     +440     
==========================================
+ Hits        13423    13861     +438     
- Misses       1408     1410       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.