[samgerene]

Fixes #67

Problem

ArgusPipeHostOptions accepted any value. An invalid one failed later, deep inside the host: a zero limit stopped the hosted service when it started listening, and a negative timeout made every request fail with only "Pipe request handling failed." in the log.

Change

Every option validates in its setter, like ArgusRetryPolicy, ArgusCompressionOptions and ArgusClient.MaxResponseBodySize already do. That covers a host built through AddArgusPipeHost as well as one constructed directly, without an IValidateOptions and without re-checking in the host.

Option	Accepted
PipeName	not null, empty or white space
MaxConcurrentRequests, MaxConcurrentConnections, MaxRequestHeaderSize	greater than zero
MaxRequestBodySize	zero (no limit) or greater
RequestReadTimeout, RequestTimeout, ResponseWriteTimeout	1 ms up to about 49.7 days, or Timeout.InfiniteTimeSpan
ShutdownDrainTimeout	zero up to about 49.7 days, or Timeout.InfiniteTimeSpan

• The exception names the option and carries the rejected value.
• Zero is rejected for the three request timeouts: it does not throw in the timers but cancels at once, so no request could be read or answered. A value under 1 ms is rejected for the same reason, because the timers count whole milliseconds.
• The upper limit is the longest duration CancelAfter and Task.Delay accept; TimeSpan.MaxValue would throw there.
• With AddArgusPipeHost(o => ...) the exception surfaces when the host creates its hosted services. Options bound from configuration are set by the binder through reflection, so there the host fails with a TargetInvocationException whose inner exception names the option. Both paths have a test.

Behavior change

A host configured with an invalid value used to start and now fails at startup. A negative MaxRequestBodySize silently meant "no limit"; use 0 for that.

Changelog

This PR also starts CHANGELOG.md (Keep a Changelog format):

• Releases 0.1.0 to 1.2.1 are reconstructed from the PackageReleaseNotes at each tag, which match the GitHub release notes.
• Unreleased lists the 32 commits merged since 1.2.1, written from their titles, plus this change.
• The 1.0.0 notes say "fixes #114" for the server request timeout; the changelog links [Feature]: Add configurable request processing timeout on server #14, which is the issue with that title.
• CLAUDE.md gets the rule that a pull request with a user-visible change adds a line under Unreleased.

Issue check

Point in #67	Result
MaxConcurrentConnections / MaxConcurrentRequests of 0 or less	rejected by the setter, tested
RequestReadTimeout / RequestTimeout negative	rejected, tested
MaxRequestHeaderSize of 0 or less	rejected, tested
MaxRequestBodySize negative	rejected, tested; a host test shows 0 accepts a 2 MB body
ShutdownDrainTimeout negative	rejected, tested at its boundaries
Scenario: RequestReadTimeout of -30 s from a config file	host fails to start; tested for the configure callback and for configuration binding
Fail fast with a message naming the option	every message names its option, including a null PipeName
Tests for each invalid value	ArgusPipeHostOptionsTestFixture
Comment: ResponseWriteTimeout	validated like the other two timeouts
Comment: TimeSpan.Zero for the timeouts	rejected for the three request timeouts, allowed for ShutdownDrainTimeout (cancels immediately)
Comment: PipeName null or empty	rejected
Comment: behavior change needs a release note	CHANGELOG.md and the wiki
Comment: placement must cover a directly constructed host	setter validation covers it

Verification

• dotnet build ArgusTransfer.sln: 0 warnings
• dotnet test ArgusTransfer.sln: 716 passed
• dotnet format ArgusTransfer.sln --verify-no-changes: clean
• dotnet build ArgusTransfer.sln -warnaserror: 0 warnings

Not done: host tests for ShutdownDrainTimeout zero and infinite (the drain is covered at ordinary values through the same code path), and PackageReleaseNotes, which is written at release time.

The wiki page "Server Configuration" has a new "Option Validation" section.

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud