Auto-generated by build.ps1 -CommitArtifacts. Build 2026.06.05.0215. Module DLL and manifest embed BuildCommitHash=82f99ea7d4a4, matching the source commit they were produced from.
The -List switch was a no-op marker on the default parameter set of six
Get-* cmdlets. Each cmdlet was declared with DefaultParameterSetName = "List"
and the -List switch was the only parameter unique to that set, so it served
no purpose beyond visual decoration: omitting it already routed to List
(because it was the default) and supplying it produced identical behavior.
REMOVED -List from
- Get-InfisicalCertificate
- Get-InfisicalEnvironment
- Get-InfisicalFolder
- Get-InfisicalProject
- Get-InfisicalSecret
- Get-InfisicalTag
UNCHANGED
- DefaultParameterSetName = "List" remains on each cmdlet.
- All other parameters on the List set (filters, ProjectId, etc.) remain
on ParameterSetName = "List" and continue to disambiguate List vs Single.
- The Single set still requires its keying parameter (-SerialNumber,
-SecretName, -EnvironmentSlugOrId, -FolderNameOrId, -TagSlugOrId,
-ProjectId on Get-InfisicalProject) to opt into single mode.
BREAKING
- Scripts that pass -List explicitly (e.g. `Get-InfisicalSecret -List ...`)
must drop the switch. No other call shape changes.
TESTS
- PkiEndpointRegistryTests.GetInfisicalCertificate_Cmdlet_Exposes_List_Filter_Properties
no longer asserts the presence of a "List" property.
- 216/216 tests passing.
Search-InfisicalCertificate was a 1:1 duplicate of Get-InfisicalCertificate's
List parameter set after the recent filter-surface expansion (bdec5aa). Both
cmdlets exposed the same ~27 server-side filters and both hit the same
POST /api/v1/projects/{projectId}/certificates/search endpoint. Keeping two
PowerShell cmdlets for the same operation added discovery noise without
benefit.
REMOVED
- src/PSInfisicalAPI/Cmdlets/SearchInfisicalCertificateCmdlet.cs (cmdlet
source, ~140 lines).
- 'Search-InfisicalCertificate' from CmdletsToExport in the source manifest
(Module/PSInfisicalAPI/PSInfisicalAPI.psd1) and from the two generators
in build.ps1 (Write-Manifest cmdlet list + Test-ModuleImports $expectedCmds).
- <command:command> block for Search-InfisicalCertificate from the help XML
(Module/PSInfisicalAPI/en-US/PSInfisicalAPI.dll-Help.xml).
- README PKI table row for Search-InfisicalCertificate.
- "For advanced filtering ... use Search-InfisicalCertificate instead"
sentence from the Get-InfisicalCertificate Notes block (no longer true).
RETAINED (internal)
- InfisicalPkiClient.SearchCertificates, InfisicalCertificateSearchQuery,
InfisicalEndpointNames.SearchCertificates and the endpoint registry entry.
Get-InfisicalCertificate and Request-InfisicalCertificate still call them
to walk the search endpoint.
MIGRATION
# Before
Search-InfisicalCertificate -ProjectId $p -Search 'web' -Status 'active'
# After
Get-InfisicalCertificate -ProjectId $p -Search 'web' -Status 'active'
Parameter names, defaults, and paging behavior are identical.
TESTS
- 216/216 passing (one unrelated time-based test in CsrAndRequestCmdletTests
was flaky on the run; passes deterministically when invoked in isolation).
Auto-generated by build.ps1 -CommitArtifacts. Build 2026.06.05.0205. Module DLL and manifest embed BuildCommitHash=86968c18cb15, matching the source commit they were produced from.
Get-InfisicalCertificatePolicy was throwing JsonSerializationException on
every list/get call:
Cannot deserialize the current JSON array (e.g. [1,2,3]) into type
'PSInfisicalAPI.Pki.InfisicalCertificatePolicySubjectDto' because the type
requires a JSON object ... Path 'certificatePolicies[0].subject', line 1,
position 207.
The API returns `subject` as an array of {type, allowed} entries (one per
DN component: CN, O, OU, C, ...), in the same shape as `sans`. The DTO
modeled it as a single object, so deserialization failed before any data
ever reached the caller.
CHANGES
- InfisicalCertificatePolicy.Subject is now InfisicalCertificatePolicySubject[]
(was a single InfisicalCertificatePolicySubject).
- DTO field switched from typed InfisicalCertificatePolicySubjectDto to
JToken SubjectRaw so we tolerate both array (current API) and object
(defensive fallback) shapes -- same pattern as SansRaw.
- Mapper gains MapSubjects(JToken) / MapSubjectObject(JToken) mirroring
MapSans / MapSanObject.
BREAKING
- The Subject property type changed from a single object to an array.
Existing consumers writing `$policy.Subject.Allowed` must update to
`$policy.Subject[0].Allowed` or iterate `$policy.Subject`. In practice no
caller was reachable because the cmdlet threw before returning.
TESTS
- 216/216 tests passing.
GraceSolutions