fix(api): declare UTF-8 plain-text ETL success responses

[seonghobae]

Purpose

Advance #235 test-first from exact protected develop@622e5e6c3d534f230c390f10e3832efadfc01825. The synchronous ETL success body is text/plain and can contain accepted non-ASCII record identifiers, but protected EtlController historically did not declare a charset.

This remains a direct-develop, bounded Draft. It changes only the successful response media type, a focused MVC regression, and touched public Javadoc. It does not change response data, error media types, authentication, ETL semantics, persistence, connector discovery, dependencies, or status codes.

Exact current identity

• protected/live base: develop@622e5e6c3d534f230c390f10e3832efadfc01825;
• branch: fix/etl-utf8-text-response-622e5e6;
• fail-first source head: caaa70115e662a136fc50184d8e9ee0fcbc49ec8;
• exact current GREEN source: 026d408427f2ead6c1735f2837cae2f73786b54f;
• current synthetic merge preview: a8a0fa884737a533c212be4fd501528d1d24d22b;
• GitHub mergeability: true;
• Draft: true;
• formal reviews: none;
• unresolved review threads: zero.

Every check/review from the fail-first head is historical after this source movement and does not transfer as current-head acceptance evidence.

RED — hosted MVC proof

EtlControllerUtf8ResponseTest reaches the real Spring MVC controller response boundary with non-ASCII result Processed: 레코드_α and requires exact Content-Type: text/plain;charset=UTF-8 while preserving the body.

CI run 31382750040, macOS job 93436332668, checked out synthetic merge dcc3eea569cc709ee909ccf1223465162af6f20f (Merge caaa701... into 622e5e6...). Production/test compilation succeeded. The new test then failed exactly:

expected:<text/plain;charset=UTF-8> but was:<text/plain>.

All existing EtlControllerTest tests were green, and ETL reported 276 tests with exactly one failure and zero errors/skips. This is valid RED at the intended HTTP representation boundary rather than a setup/import/dependency failure. It is merged-tree development evidence, not literal-source proof.

GREEN implementation and current evidence

Exact current source head 026d408427f2ead6c1735f2837cae2f73786b54f applies the smallest root-cause correction proven by RED:

• defines the successful representation as text/plain with explicit UTF-8 charset using Spring MediaType;
• preserves the response body and idempotency metadata;
• keeps application/problem+json failure handling unchanged;
• updates the touched public Javadoc to describe the UTF-8 success representation.

All exposed workflow aggregates associated with this exact source head are terminal-success:

• CI 31382890040: success on Ubuntu, macOS and Windows;
• Dependency Review 31382890205: success;
• CycloneDX SBOM 31382890400: success;
• SAST Semgrep 31382890299: success;
• Security Scan 31382890168: aggregate success.

CI macOS job 93436769799 checked out synthetic merge a8a0fa884737a533c212be4fd501528d1d24d22b, not literal source. It ran the focused UTF-8 MVC test 1/1 green, EtlControllerTest 23/23 green, ETL 276/276 green, CDC 106/106 green, gateway 3/3 green, and the full reactor completed successfully.

The same job still reports Analyzed bundle 'etl-service' with 0 classes before declaring coverage checks met. Therefore the aggregate cannot serve as accepted non-vacuous 100% owned-production coverage evidence; #162/#164 owns the selected bundle and #205 owns repository-wide scope. The current hard-scanner aggregate also remains subject to #196 dependency-graph completeness. No formal review or independent exact-head approval exists.

Standards basis

RFC 6657 preserves the historical US-ASCII default for text/plain when charset is absent and recommends sender-provided charset information rather than recipient guessing. The runtime already accepts and emits Unicode identifiers, so the HTTP success boundary must explicitly declare UTF-8.

Melnikov, A., & Reschke, J. (2012). Update to MIME regarding "charset" parameter handling in textual media types (RFC 6657). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc6657

Shared acceptance boundary

This PR does not repair literal-source workflow identity (#121/central dependencies), protected selected-bundle non-vacuity (#162/#164), repository-wide coverage scope (#205), Maven scanner dependency-graph completeness (#196), Maven resource reproducibility (#217), or direct service authentication (#161). Those independent controls must not be folded into this two-file response-encoding slice.

Merge boundary

Keep Draft. Protected merge requires the unchanged exact source head to have accepted literal-source deterministic/security evidence, complete same-revision vulnerability/dependency evidence, non-vacuous applicable owned-production coverage, every current required gate, zero valid unresolved findings, and qualifying independent formal approval where governance requires it. Synthetic merge, predecessor-head, pending, skipped-required, incomplete-scanner or status-only evidence is not passing.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 0113cfe2-1163-4aef-a95d-a362c2b27694

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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.}