Skip to content

Tech debt

No CRITICAL findings were identified. The HIGH findings below center on the absence of any resilience posture (retry, timeout intent, cancellation) and on packaging choices that ship source and unused dependencies to every consumer.

CRITICAL

No CRITICAL findings identified for this package.

HIGH

Finding Component Impact Recommended action
No retry policy on any member — no Polly reference, RetryPolicy, or retry loop anywhere in PdfAPI.Client PdfClient (all 5 remote members) Every transient HTTP failure surfaces directly to the caller with no automatic recovery Add a retry policy (e.g. Polly) around the JsonHttpClient calls, or document the expectation that consumers must implement their own retry
No timeout is specified when constructing JsonHttpClient (new JsonHttpClient(baseUri, info)); the effective timeout is whatever JsonHttpClient defaults to, and that default could not be verified from source available to this run** PdfClient..ctor (PdfAPI.Client\PdfClient.cs:18) Long-running operations (conversion, merge) have no stated, intentional bound; a caller cannot reason about worst-case call duration Pass an explicit timeout to JsonHttpClient and document the chosen value
No CancellationToken on any member; a caller cannot abandon an in-flight call IPdfClient, PdfClient (all members) A caller blocked on a long-running conversion or merge call has no way to cancel it Add CancellationToken overloads where the underlying JsonHttpClient API supports them
.Results.FirstOrDefault() on the four PostJson<T> call sites converts an empty result collection into default(T) — false for IsPdfa, null for Convert/Merge — with no exception and no diagnostic PdfClient.Convert (both overloads), Merge, IsPdfa A failed call is indistinguishable from a genuinely empty/negative response, which can silently mask errors for consumers Throw or otherwise surface a distinguishable failure when Results is empty, rather than falling through to the type default
The package ships C# source (src\PdfAPI.Client, src\PdfAPI.Core) alongside the compiled assemblies via the nuspec <files> element Scripts\PdfAPI.Client\PdfAPI.Client.nuspec Every consumer receives the full implementation source, inviting forking and drift between the shipped source and the shipped binary; any embedded comment or internal detail ships with the package Evaluate whether source shipping is still required for this package, and if so, document the intended consumer use of the src\ payload
A token-template nuspec (PdfAPI.Client\PdfApi.Client.nuspec, <id>$id$</id> with an empty <files/>) remains in the project folder alongside the real manifest, differing only in filename casing (PdfApi vs PdfAPI) PdfAPI.Client\PdfApi.Client.nuspec A future contributor could mistake the token template for the packaging manifest, or a build change could accidentally pick it up Remove the unused token-template nuspec, or rename it unambiguously to signal it is a Visual Studio scaffold artifact
Autofac 3.5.2 and log4net 2.0.5 are referenced by the project with no ContainerBuilder registration and no logging call anywhere in client code PdfAPI.Client\PdfAPI.Client.csproj Unnecessary build-time dependencies increase the project's attack/update surface for no functional benefit Remove the unused references
The release pipeline packs a Debug-configuration build (BuildConfiguration: debug) Pipelines\build-vars-client.yml The package shipped to consumers may not match the optimizations and behavior of a Release build Change the release pipeline to pack a Release-configuration build, or document why Debug is intentional
Three independent version sources disagree: manifest version 1.0.0.3, assembly version 1.0.0.0, and the pipeline-generated build number Scripts\PdfAPI.Client\PdfAPI.Client.nuspec; PdfAPI.Client\Properties\AssemblyInfo.cs Consumers cannot reliably correlate an installed package version with the assembly version reported at runtime Align the manifest version, assembly version, and pipeline versioning to a single source of truth
The app.config binding redirect pins RestSharp to 106.11.7.0 while the project references 106.12.0 PdfAPI.Client\app.config A version mismatch between the declared redirect and the actual referenced assembly can cause runtime binding failures for consumers who rely on the redirect Update the binding redirect to match the referenced RestSharp version
The packaged lib\net45 target folder does not match the project's net462 compile target Scripts\PdfAPI.Client\PdfAPI.Client.nuspec A consumer restoring the package may resolve an assembly folder that does not reflect the actual compiled framework version Align the nuspec <files> target folder with the project's actual target framework, or document the discrepancy as intentional

Note: Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • PdfAPI.Client\PdfClient.cs
  • PdfAPI.Client\PdfAPI.Client.csproj
  • PdfAPI.Client\PdfApi.Client.nuspec
  • PdfAPI.Client\app.config
  • PdfAPI.Client\Properties\AssemblyInfo.cs
  • Scripts\PdfAPI.Client\PdfAPI.Client.nuspec
  • Pipelines\build-vars-client.yml