LEGLINK-889: Add cached ValueSet member lookup and harden CSV status parsing

[MikeAtPinnacle]

🛠️ Description of Changes

Adds the missing cached-ValueSet-member lookup that LEGLINK-889 turned out to need, hardens CSV status parsing so one bad cell cannot drop a whole code group, and brings along the in-memory CSV upload endpoints so QA can set up terminology fixtures without editing the shared data volume.

LEGLINK-889 — what the ticket actually was

The report was that marking a code inactive and reading it back through GET /config/code-systems/{id}/codes/{code} always answers Active. Reproducing it from TestRail 10977 showed the case marks postal inactive in the ValueSet CSV and then reads the CodeSystem back. Those are two separate cached code groups from two separate directories, and the code system's own codes are never touched by that case — so Active was the correct answer. Ingestion, lookup and serialization were each verified to handle Inactive correctly and are covered by existing tests.

The real gap was that nothing could read a cached value set member's own membership status back.

• Add GET /api/terminology/config/value-sets/{id}/codes/{code}, with optional system and version. It reports membershipStatus (what the value set itself declares, null when its CSV has no status column) alongside effectiveStatus (what actually applies). Two values rather than one because conflating them is what produced this ticket: null is not Active, it means the value set said nothing and the question defers to the code system.
• Member selection mirrors ValueSet/$validate-code exactly — an explicit system narrows the search, otherwise the first system listing the code wins, and within a system the last occurrence wins (LEGLINK-599/814).
• Make FhirService.ResolveIsActive public as ResolveCodeStatus, so the new endpoint and $validate-code resolve status through one implementation rather than two that can drift apart.
• Declare CodeSystemCode as the code system lookup's response type, so Swagger documents the status field it has always returned on the wire.
• Sanitize/decode consistently across all three config endpoints, so a code or system URI containing a reserved character still matches the cache. FhirController already did this; the two disagreeing is the class of defect this ticket is about.

CSV status parsing

• Read the status column as a string and interpret it in the loader. CsvHelper's enum converter threw on any unrecognized value, and because records enumerate lazily, that throw escaped ProcessCodeSystemCsv, was swallowed by LoadCache, and cost the entire code group — thousands of good codes lost to one typo, with the group then answering 404. Both loaders now default the row to Active and log one warning per file naming the offending codes. The ValueSet loader already defaulted, but silently.
• The warning is aggregated per file rather than per row: these loops run once per code and a large code system carries hundreds of thousands.

Terminology CSV upload (rides along)

• Add PUT /api/terminology/config/value-sets/{id}/codes and .../code-systems/{id}/codes (multipart, part name file), answering 202 with the resulting code, system, and inactive-code counts. Nothing is written to Terminology:Path, the FHIR resource metadata is preserved exactly, and POST $reload-cache reverts.
• Gated by Terminology:EnableCodeUploadEndpoint, default false, reporting 404 rather than 403 while off, so a disabled instance is indistinguishable from one that never shipped the routes. Enabled in the Development and Docker settings only, and cataloged in app-config.yaml.
• Fixes a latent bug in SetCodeGroup: CacheKey overrides neither Equals nor GetHashCode, so the ConcurrentBag.Contains guard was reference equality and never matched. Harmless while LoadCache (which clears first) was the only caller, but every replace would leak a duplicate key.

The two halves compose well: ReplaceCodesFromCsv calls the same Process*Csv methods this PR hardens, so an uploaded CSV carrying an unrecognized status now defaults that row and warns instead of throwing the whole upload away.

Also included

• TECH_DEBT: refresh DotNet/MockDmrpApi/packages.lock.json. It was the only project whose committed lock file predated a package graph shift that every other project already carries, so a restore regenerated it and left the file dirty for anyone building that project. No package reference changes.

🧪 Testing Performed

• dotnet test DotNet/ServiceTests/ServiceTests.csproj --filter FullyQualifiedName~UnitTests — 1584 unit tests pass, and the solution builds clean.
• Serialization was ruled out as a cause for LEGLINK-889 by standing up a minimal MVC host with the same shape (derived object returned through ActionResult<Code>); the response body carries "status":"Inactive", confirming MVC serializes by runtime type and only the documented Swagger type was wrong.
• CsvHelper 33.1.0's behavior on an unrecognized status was confirmed standalone before the change: it throws TypeConverterException mid-enumeration, which is what cost the whole file.
• The upload endpoints were verified previously against the local docker-compose stack: uploading one code to v3-ActEncounterCode took its expansion from 11 codes to 1, a former member stopped validating while the injected code validated with its inactive warning, the resource metadata and the CSV on disk were both untouched, empty/wrong-column/unknown-id/non-csv/wrong-type requests returned 400 or 404 without disturbing the override, and $reload-cache restored all 11 codes.

🧑‍🔬 Unit Testing

• I have written or updated unit tests to cover my changes
• Coverage: 96.7%
  • ConfigControllerTests — 13 new cases for GetValueSetCode (400/404 shapes, declared membership status wins in both directions, rejoin from the code system when the value set declares nothing, null vs Active, system filtering, first-system-wins, last-occurrence-wins, blank-parameter handling), plus existing GetCodeSystemCode cases updated for the CodeSystemCode response type. The cache is now mocked at ICodeGroupCacheService with a real FhirService sharing it, so the status reported is resolved by the same code $validate-code uses.
  • CodeGroupCacheServiceTests — a theory over three kinds of unrecognized status asserting the code group survives and only the bad row defaults, the equivalent for the ValueSet loader, and verification that the warning is logged once per file. Plus the upload branch's ReplaceCodesFromCsv coverage (unknown target, wrong column count leaves the cache intact, repeated replaces do not accumulate cache keys, malformed-CSV handling).

📓 Documentation Updated

• app-config.yaml — catalogued Terminology:EnableCodeUploadEndpoint (required: false, defaultValue: "false").
• docs/config-key-inventory.md — regenerated for the new key.
• XML documentation on every new public member, including why ValueSetCodeLookupResult reports two statuses and why the CSV status column is read as a string.

Summary by CodeRabbit

• New Features
  • Added ValueSet code lookup with system, membership, and effective-status details.
  • Added configurable CSV replacement endpoints for ValueSets and CodeSystems, including validation and replacement summaries.
  • Added upload controls that are disabled by default and enabled in supported environments.
• Bug Fixes
  • Improved handling of invalid or missing CSV statuses by defaulting them to Active.
  • Prevented duplicate cached entries and preserved code-group metadata during replacements.
• Documentation
  • Updated configuration documentation with the new upload setting.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR adds ValueSet code lookup and gated CSV replacement endpoints. It introduces replacement models and configuration, preserves metadata during cache updates, normalizes CSV statuses, exposes effective status resolution, and adds controller and service test coverage.

Changes

Terminology flow

Layer / File(s)	Summary
Contracts and settings DotNet/Terminology/Application/Interfaces/ICodeGroupCacheService.cs, DotNet/Terminology/Application/Models/*, DotNet/Terminology/Application/Settings/TerminologyConfig.cs	Adds the CSV replacement contract, lookup and replacement response models, upload configuration, and nullable raw CSV status handling.
Cache replacement and status processing DotNet/Terminology/Services/CodeGroupCacheService.cs, DotNet/Terminology/Services/FhirService.cs, DotNet/ServiceTests/UnitTests/Terminology/Services/CodeGroupCacheServiceTests.cs	Replaces cached codes without mutating prior instances, preserves metadata, removes duplicate cache keys, normalizes invalid statuses to Active, aggregates warnings, and resolves effective code status.
Lookup and upload endpoints DotNet/Terminology/Controllers/ConfigController.cs	Adds ValueSet lookup, updates CodeSystem responses, validates decoded lookup inputs, and processes gated multipart CSV replacements with structured errors and summaries.
Controller behavior coverage DotNet/ServiceTests/UnitTests/Terminology/Controllers/ConfigControllerTests.cs	Tests ValueSet matching, system and version selection, status precedence, CodeSystem response types, upload validation, feature gating, error mapping, successful replacement, and version normalization.
Runtime configuration DotNet/Terminology/appsettings*.json, app-config.yaml, docs/config-key-inventory.md	Configures upload endpoints for development and Docker environments, keeps the default disabled, and updates the configuration inventory.

Estimated code review effort: 4 (Complex) | ~60 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant ConfigController
  participant ICodeGroupCacheService
  participant CodeGroupCacheService
  Client->>ConfigController: Upload CodeSystem or ValueSet CSV
  ConfigController->>ConfigController: Validate feature flag, file, identifier, and CSV shape
  ConfigController->>ICodeGroupCacheService: ReplaceCodesFromCsv(type, id, version, csvContent)
  ICodeGroupCacheService->>CodeGroupCacheService: Parse CSV and publish replacement
  CodeGroupCacheService-->>ConfigController: Return replaced CodeGroup
  ConfigController-->>Client: Return ReplaceCodesResponse

Loading

Possibly related PRs

• lantanagroup/link-cloud#1765: Modifies related ConfigController and FhirService duplicate-code status resolution.
• lantanagroup/link-cloud#1769: Adds related ValueSet membership-status behavior.
• lantanagroup/link-cloud#1777: Shares terminology lookup validation and input sanitization paths.

Suggested reviewers: seanmcilvenna, johnbritton

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 23.38% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies cached ValueSet member lookup and CSV status parsing as the primary changes.
Description check	✅ Passed	The description completes all template sections and provides detailed change scope, testing evidence, unit coverage, and documentation updates.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch users/mtherien/leglink-889-fix-test-endpoint

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 5

🧹 Nitpick comments (5)

DotNet/Terminology/Controllers/ConfigController.cs (2)

108-110: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Declare the Problem Details response types in the Swagger annotations.

The 400 and 404 responses return ValidationProblemDetails or ProblemDetails, but the attributes declare no Type. The generated OpenAPI document therefore describes these responses without a schema, so clients cannot generate error models. The controller path instructions require Swagger/OpenAPI documentation for every API.

♻️ Proposed change for the lookup endpoints

     [ProducesResponseType(StatusCodes.Status200OK, Type = typeof(CodeSystemCode))]
-    [ProducesResponseType(StatusCodes.Status400BadRequest)]
-    [ProducesResponseType(StatusCodes.Status404NotFound)]
+    [ProducesResponseType(StatusCodes.Status400BadRequest, Type = typeof(ValidationProblemDetails))]
+    [ProducesResponseType(StatusCodes.Status404NotFound, Type = typeof(ProblemDetails))]

As per coding guidelines: "Implement Swagger/OpenAPI documentation for every API".

Also applies to: 183-185, 321-323, 364-366

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@DotNet/Terminology/Controllers/ConfigController.cs` around lines 108 - 110,
Update the Swagger annotations for the lookup endpoints in ConfigController,
including the response declarations near the referenced blocks, to specify
ValidationProblemDetails for 400 responses and ProblemDetails for 404 responses.
Apply the same response Type metadata consistently to every affected endpoint
while preserving the existing status codes and success response documentation.

Source: Path instructions

---

432-436: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low value

Bound the read by the validated length instead of reading an unbounded stream.

file.Length was already checked against MaxCsvUploadBytes, so this read is bounded in practice. One detail is worth confirming: StreamReader decodes without a byte order mark check argument, so a UTF-8 BOM stays in the first field of the first row. The header row is skipped, so the BOM is harmless today. If a caller ever posts a headerless file, the first system value contains the BOM and the match fails silently.

Consider new StreamReader(file!.OpenReadStream(), Encoding.UTF8, detectEncodingFromByteOrderMarks: true) to remove the ambiguity.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@DotNet/Terminology/Controllers/ConfigController.cs` around lines 432 - 436,
Update the StreamReader setup used to populate csvContent so reading is
explicitly limited to the already validated file.Length (capped by
MaxCsvUploadBytes), rather than relying on an unbounded stream. Configure UTF-8
decoding with BOM detection enabled so a leading BOM is removed before parsing
system values, while preserving the existing cancellation-aware read.

DotNet/ServiceTests/UnitTests/Terminology/Controllers/ConfigControllerTests.cs (1)

533-559: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add a test for the oversize-file branch.

The upload validation has four file branches: null, empty, oversize, and non-.csv extension. Tests cover three. The file.Length > MaxCsvUploadBytes branch at ConfigController.cs Line 408 has no test, so a regression in the limit or the message would not be detected.

A stubbed IFormFile with a reported Length above the limit avoids allocating 32 MB in the test.

💚 Proposed test

[Fact]
public async Task ReplaceValueSetCodes_FileTooLarge_Returns400WithFileError()
{
    var file = new Mock<IFormFile>();
    file.SetupGet(x => x.Length).Returns(33L * 1024 * 1024);
    file.SetupGet(x => x.FileName).Returns("codes.csv");

    var result = await _controller.ReplaceValueSetCodes(UploadValueSetId, file.Object);

    var problem = AssertProblem(result, StatusCodes.Status400BadRequest);
    Assert.Contains("file", Assert.IsType<ValidationProblemDetails>(problem).Errors.Keys);
    _mockCacheService.Verify(
        x => x.ReplaceCodesFromCsv(It.IsAny<CodeGroup.CodeGroupTypes>(), It.IsAny<string>(), It.IsAny<string?>(), It.IsAny<string>()),
        Times.Never);
}

As per path instructions: "If/Else or Switch/Case blocks are introduced or modified — ensure each branch has a corresponding unit test."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@DotNet/ServiceTests/UnitTests/Terminology/Controllers/ConfigControllerTests.cs`
around lines 533 - 559, Add a unit test alongside the existing
ReplaceValueSetCodes file-validation tests covering the oversize branch in
ReplaceValueSetCodes. Use a mocked IFormFile reporting a Length above
MaxCsvUploadBytes with a .csv filename, assert a 400 response containing a file
validation error, and verify _mockCacheService.ReplaceCodesFromCsv is never
called.

Source: Path instructions

DotNet/ServiceTests/UnitTests/Terminology/Services/CodeGroupCacheServiceTests.cs (1)

678-782: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add a case with several unrecognized rows to prove aggregation.

Every unrecognized-status test uses exactly one bad row. Times.Once therefore passes even if the loader logged one warning per bad row. Add a CSV with two or more unrecognized statuses and keep Times.Once. That assertion is the one that verifies the per-file aggregation this change introduces. Asserting that the message names both offending codes also covers CodeStatusParser.Examples.

Based on path instructions: "If/Else or Switch/Case blocks are introduced or modified — ensure each branch has a corresponding unit test."

💚 Proposed additional test

[Fact]
public async Task LoadCache_MultipleUnrecognizedStatuses_LogsOneWarningNamingEachCode()
{
    using var memoryCache = new MemoryCache(new MemoryCacheOptions());
    var mockConfig = new Mock<IOptions<TerminologyConfig>>();
    mockConfig.Setup(x => x.Value).Returns(_config);

    var directoryFiles = new Dictionary<string, string[]>
    {
        ["/test/path/cs"] = new[] { "cs.json", "cs.csv" }
    };
    var fileContents = new Dictionary<string, string>
    {
        ["cs.json"] = "{ \"resourceType\": \"CodeSystem\", \"id\": \"test-cs\", " +
                      "\"url\": \"http://test.codesystem\", \"version\": \"1.0\" }",
        ["cs.csv"] = "code,display,status\r\n" +
                     "123,One,Retired\r\n" +
                     "456,Two,Bogus\r\n" +
                     "789,Three,Inactive\r\n"
    };

    var service = new TestableCodeGroupCacheService(
        _loggerMock.Object, memoryCache, mockConfig.Object, directoryFiles, fileContents);

    await service.LoadCache();

    // One warning for the whole file, naming both offending codes.
    _loggerMock.Verify(
        x => x.Log(
            LogLevel.Warning,
            It.IsAny<EventId>(),
            It.Is<It.IsAnyType>((v, _) =>
                v.ToString()!.Contains("unrecognized status") &&
                v.ToString()!.Contains("123") &&
                v.ToString()!.Contains("456")),
            It.IsAny<Exception>(),
            It.IsAny<Func<It.IsAnyType, Exception?, string>>()),
        Times.Once);
}

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@DotNet/ServiceTests/UnitTests/Terminology/Services/CodeGroupCacheServiceTests.cs`
around lines 678 - 782, Add a test near
LoadCache_CodeSystemUnrecognizedStatus_KeepsTheCodeSystemAndDefaultsTheRow with
multiple unrecognized status rows in the same CSV, such as codes 123 and 456,
plus a valid row. Verify both malformed rows default to Active, the file remains
cached, and the warning is logged exactly once with a message containing
“unrecognized status” and both offending codes, covering per-file aggregation
and CodeStatusParser.Examples.

Source: Path instructions

DotNet/Terminology/Services/CodeGroupCacheService.cs (1)

195-207: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick win

Replace the check-then-add guard with a keyed concurrent collection.

The duplicate-key fix is correct in intent, but the guard is not atomic. _cacheKeys.Any(...) followed by _cacheKeys.Add(...) is a check-then-act sequence on a ConcurrentBag. Two concurrent SetCodeGroup calls for the same composite key can both observe "absent" and both add. The upload endpoint makes concurrent calls reachable, because this service is a singleton and ReplaceCodesFromCsv runs on request threads.

The scan is also O(n) per call, so LoadCache becomes O(n²) in the number of cached groups.

A ConcurrentDictionary<string, CacheKey> keyed on CacheKey.Key removes both problems. It needs matching updates in GetCodeGroupById, GetCodeGroup, GetAllCodeGroups, and ClearCache, so it is a follow-up rather than a blocker.

♻️ Sketch of the keyed-collection change

-    private readonly ConcurrentBag<CacheKey> _cacheKeys = new ConcurrentBag<CacheKey>();
+    private readonly ConcurrentDictionary<string, CacheKey> _cacheKeys = new(StringComparer.Ordinal);

     protected internal virtual void SetCodeGroup(CodeGroup codeGroup)
     {
         CacheKey urlKey = new CacheKey((CodeGroup.CodeGroupTypes)codeGroup.Type!, codeGroup.Url!, codeGroup.Version!, codeGroup.Id!, codeGroup.Identifiers);
         cache.Set(urlKey.Key, codeGroup, _cacheOptions);
-
-        if (!_cacheKeys.Any(k => string.Equals(k.Key, urlKey.Key, StringComparison.Ordinal)))
-            _cacheKeys.Add(urlKey);
+        _cacheKeys[urlKey.Key] = urlKey;
     }

Reads then iterate _cacheKeys.Values, and ClearCache uses _cacheKeys.Clear().

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@DotNet/Terminology/Services/CodeGroupCacheService.cs` around lines 195 - 207,
Replace the ConcurrentBag-based _cacheKeys collection with a
ConcurrentDictionary<string, CacheKey> keyed by CacheKey.Key, and update
SetCodeGroup to assign via the dictionary indexer so duplicate inserts are
atomic and constant-time. Adjust GetCodeGroupById, GetCodeGroup, and
GetAllCodeGroups to iterate _cacheKeys.Values, and update ClearCache to call
_cacheKeys.Clear() while preserving existing cache behavior.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@DotNet/ServiceTests/UnitTests/Terminology/Controllers/ConfigControllerTests.cs`:
- Around line 404-422: Update
GetValueSetCode_NoSystemSupplied_TakesFirstSystemListingTheCode so it does not
depend on Dictionary enumeration order: assert that lookup.System is either
otherSystem or AddressTypeSystem, then assert MembershipStatus matches the
corresponding system’s expected status (Active for otherSystem, Inactive for
AddressTypeSystem). Only change the cache structure if the surrounding
implementation explicitly requires load-order semantics.

In
`@DotNet/ServiceTests/UnitTests/Terminology/Services/CodeGroupCacheServiceTests.cs`:
- Around line 1267-1284: The regression test does not directly verify that
duplicate cache keys are avoided. Add an internal CacheKeyCount member to
CodeGroupCacheService exposing _cacheKeys.Count, then update
ReplaceCodesFromCsv_RepeatedReplaces_DoNotAccumulateCacheKeys to assert the
expected single key after repeated replacements while retaining the existing
behavior assertions.

In `@DotNet/Terminology/appsettings.Docker.json`:
- Around line 4-5: Update the shared Docker configuration’s
EnableCodeUploadEndpoint setting to false, and provide any required test-only
override separately so code-upload routes are enabled only explicitly during
tests.

In `@DotNet/Terminology/Controllers/ConfigController.cs`:
- Around line 374-390: Protect the terminology upload actions
ReplaceValueSetCodes and ReplaceCodeSystemCodes with authorization that always
requires an authenticated user and the required permission, independent of
Authentication:EnableAnonymousAccess and permissive shared policies. Add the
authorization metadata or explicit checks at the controller/action level, while
preserving the existing disabled-endpoint 404 behavior in ReplaceCodesAsync.

In `@DotNet/Terminology/Services/CodeGroupCacheService.cs`:
- Around line 504-526: Update the Parse method’s invalid-status example
construction to truncate both code and rawStatus before appending, ensuring each
formatted entry remains bounded and the overall _examples value stays within
MaxExampleLength. Preserve the existing separator, invalid-count increment,
fallback status, and LogInvalidStatusWarning sanitization behavior, and align
the implementation with the XML remark describing truncated examples.

---

Nitpick comments:
In
`@DotNet/ServiceTests/UnitTests/Terminology/Controllers/ConfigControllerTests.cs`:
- Around line 533-559: Add a unit test alongside the existing
ReplaceValueSetCodes file-validation tests covering the oversize branch in
ReplaceValueSetCodes. Use a mocked IFormFile reporting a Length above
MaxCsvUploadBytes with a .csv filename, assert a 400 response containing a file
validation error, and verify _mockCacheService.ReplaceCodesFromCsv is never
called.

In
`@DotNet/ServiceTests/UnitTests/Terminology/Services/CodeGroupCacheServiceTests.cs`:
- Around line 678-782: Add a test near
LoadCache_CodeSystemUnrecognizedStatus_KeepsTheCodeSystemAndDefaultsTheRow with
multiple unrecognized status rows in the same CSV, such as codes 123 and 456,
plus a valid row. Verify both malformed rows default to Active, the file remains
cached, and the warning is logged exactly once with a message containing
“unrecognized status” and both offending codes, covering per-file aggregation
and CodeStatusParser.Examples.

In `@DotNet/Terminology/Controllers/ConfigController.cs`:
- Around line 108-110: Update the Swagger annotations for the lookup endpoints
in ConfigController, including the response declarations near the referenced
blocks, to specify ValidationProblemDetails for 400 responses and ProblemDetails
for 404 responses. Apply the same response Type metadata consistently to every
affected endpoint while preserving the existing status codes and success
response documentation.
- Around line 432-436: Update the StreamReader setup used to populate csvContent
so reading is explicitly limited to the already validated file.Length (capped by
MaxCsvUploadBytes), rather than relying on an unbounded stream. Configure UTF-8
decoding with BOM detection enabled so a leading BOM is removed before parsing
system values, while preserving the existing cancellation-aware read.

In `@DotNet/Terminology/Services/CodeGroupCacheService.cs`:
- Around line 195-207: Replace the ConcurrentBag-based _cacheKeys collection
with a ConcurrentDictionary<string, CacheKey> keyed by CacheKey.Key, and update
SetCodeGroup to assign via the dictionary indexer so duplicate inserts are
atomic and constant-time. Adjust GetCodeGroupById, GetCodeGroup, and
GetAllCodeGroups to iterate _cacheKeys.Values, and update ClearCache to call
_cacheKeys.Clear() while preserving existing cache behavior.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 6c98e5b5-6486-4dc8-8b02-b37b2e1374e2

📥 Commits

Reviewing files that changed from the base of the PR and between 8e15e7d and be496be.

📒 Files selected for processing (15)

• DotNet/ServiceTests/UnitTests/Terminology/Controllers/ConfigControllerTests.cs
• DotNet/ServiceTests/UnitTests/Terminology/Services/CodeGroupCacheServiceTests.cs
• DotNet/Terminology/Application/Interfaces/ICodeGroupCacheService.cs
• DotNet/Terminology/Application/Models/CsvCodeSystemRecord.cs
• DotNet/Terminology/Application/Models/ReplaceCodesResponse.cs
• DotNet/Terminology/Application/Models/ValueSetCodeLookupResult.cs
• DotNet/Terminology/Application/Settings/TerminologyConfig.cs
• DotNet/Terminology/Controllers/ConfigController.cs
• DotNet/Terminology/Services/CodeGroupCacheService.cs
• DotNet/Terminology/Services/FhirService.cs
• DotNet/Terminology/appsettings.Development.json
• DotNet/Terminology/appsettings.Docker.json
• DotNet/Terminology/appsettings.json
• app-config.yaml
• docs/config-key-inventory.md