Tags: devslab-kr/api-log

v3.0.1 — HTTP client fixes (Content-Type on body + PATCH method support)

Release v3.0.0

Spring-major-aligned versioning policy adoption. Renumbering of 0.6.0
to 3.0.0 to match the Spring Boot major this line targets (Spring
Boot 3). See:
https://github.com/devslab-kr/.github/blob/main/.github/VERSIONING.md

No code, API, or dependency changes. Published JAR bytes identical to
0.6.0 apart from the version coordinate.

Diag: verify SIGNING_KEY still has PGP armor header/footer

Fix conditional + obsolete bean-name assertions

Two small tail-end fixes:

- apiLogPlatformThreadExecutor wasn't registering because Spring Boot
  always provides applicationTaskExecutor, satisfying my over-broad
  @ConditionalOnMissingBean(TaskExecutor.class). Drop the conditional;
  the bean coexists with Spring Boot's default and consumers pick by name.

- allConfigurationBeans_shouldBePresent was asserting beans for the
  @configuration classes I deleted (jacksonConfig, restClientConfig,
  asyncConfig). Update to assert the three auto-configurations now
  registered via the imports file.

Restore v0.5.0 section in root CHANGELOG, add v0.5.1 above

The previous split commit left CHANGELOG.md (root) inconsistent — link refs
were updated to v0.5.1 but the v0.5.0 section header still claimed the
reactive work, with no separate v0.5.1 section. Now matches docs/changelog.md.

v0.5.0: PUT/DELETE/PATCH support + core send() API for retry correlation

Added:
- 12 new convenience methods on RestApiClientUtil — putSync/putSyncTyped/
  putAsync/putAsyncTyped/deleteSync/deleteSyncTyped/deleteAsync/
  deleteAsyncTyped/patchSync/patchSyncTyped/patchAsync/patchAsyncTyped
  (with String/typed-body/typed-response overloads where applicable).
  Fills the v0.5.0 roadmap items called out in the using-restapiclient guide.

- Core send/sendAsync/sendTyped/sendAsyncTyped methods taking
  (HttpMethod, ApiRequest) directly. The first concrete way for callers to
  share a request_id across retry attempts — pass an explicit requestId on
  the ApiRequest builder and every retry's INITIATED + SUCCESS/ERROR rows
  correlate via the same key. This was a documented limitation in v0.4.0
  (retry-handling guide); v0.5.0 closes it.

Internal cleanup:
- RestApiClientUtil refactored so all 22 convenience methods funnel through
  the four core send* methods. ~270 lines of duplicated try/catch/event-
  publish boilerplate collapsed into one place. Behavior identical — only
  the implementation is consolidated. Existing tests pass unchanged.

Tests:
- RestApiClientUtilRoutingTest (new) — verifies each verb method routes
  through the correct HttpMethod and that send(HttpMethod, ApiRequest)
  respects a caller-provided requestId.

Docs:
- using-restapiclient guide updated: full method matrix including all 5
  verbs, core API section, retry-correlation pattern with example, and the
  roadmap shrunk (PUT/DELETE/PATCH removed since now shipped).
- Changelog entries (en + ko).

Fully backward-compatible with v0.4.0.

v0.4.0: real status codes, structured error_message, honest retry docs

Bug fixes:
- RestApiClientUtil raw methods (getSync, postSync(String,String), getAsync,
  postAsync(String,String)) were hardcoding statusCode=200 regardless of the
  actual HTTP response. Switched .body(String.class) → .toEntity(String.class)
  so the real status comes through.
- ApiLogService.saveApiCallError now extracts HTTP status from Spring's
  HttpStatusCodeException / RestClientResponseException — was always NULL on
  ERROR/RETRY_ERROR rows before.
- error_message JSONB column was a raw message string; now structured as
  {type, message, responseBody?} matching what the docs always claimed.
  Added responseBody capture so vendor error bodies aren't lost.

Doc honesty pass:
- retry-handling guide rewritten. The previous version implied Spring Retry
  auto-produces RETRY_ERROR rows from RestApiClientUtil — that was false.
  Each retry through RestApiClientUtil generates a fresh request_id (no
  correlation across attempts) and the error events carry retryCount=0,
  isRetry=false hardcoded. Documented this limitation and pointed readers
  to manual event publishing for retry-timeline tracking. Added a section
  on ApiEventListener's own @retryable for log-write resilience — that's
  the real "retry-aware" feature of the starter.
- README schema columns: VARCHAR(20)/(255) → VARCHAR(50)/(36) to match
  the actual DDL.
- Removed "Production-tested" claim (couldn't back it up) and "Spring Retry
  integration with RETRY_ERROR events" claim (specifically wrong).
- Added Maven Central + CI badges + documentation link to READMEs.

Tests: added two ApiLogServiceTest cases covering structured error_message
and HTTP status extraction.

v0.3.0: BUILTIN schema management is the new default

v0.2.0 made schema management opt-in (default NONE) which forced users without
Flyway/Liquibase to copy DDL manually before their first run. That was poor UX
for the most common case.

v0.3.0 flips the default to BUILTIN — the starter runs CREATE TABLE IF NOT EXISTS
on every startup via Spring Boot's DataSourceScriptDatabaseInitializer. The SQL
is idempotent (IF NOT EXISTS clauses), so re-running on every boot is a no-op
once the table exists.

Three strategies now:
- BUILTIN (default) — starter creates the table; no migration tool needed
- FLYWAY — appends classpath:db/api-log to spring.flyway.locations
- NONE — starter does not touch the schema; consumer applies the DDL

Implementation:
- ApiLogProperties.Schema.Management: BUILTIN, FLYWAY, NONE (default BUILTIN)
- ApiLogSchemaInitializer extends DataSourceScriptDatabaseInitializer so
  JpaBaseConfiguration auto-DependsOn it — the EntityManagerFactory waits for
  schema creation before validating entities (avoids ddl-auto=validate failure
  on fresh DBs).
- V1.0__create_api_log.sql: added IF NOT EXISTS to CREATE TABLE and CREATE INDEX
  statements. Flyway is fine with this (it tracks migrations by version, not
  by SQL effect).

Tests pinned to schema.management=builtin in src/test/resources/application.properties.

Docs (installation, quickstart, configuration ref, schema ref, changelog) updated
to lead with BUILTIN; FLYWAY and NONE are documented as alternatives for teams
with specific schema-management policies.

Breaking from v0.2.0 only for users who relied on the v0.2.0 NONE default; full
migration notes in docs/changelog.md.

Stop ignoring src/test/resources/application.properties

v0.2.0 needs a test fixture that opts into Flyway so the existing
@SpringBootTest classes find the api_log table. The blanket
'application.properties' .gitignore rule swallowed it, so the previous
commit (751ea19) shipped without it — CI is going to fail because the
4 Testcontainers-based tests can't bootstrap.

Add an !exception scoped to src/test/resources/ so production configs
stay ignored (security) but test fixtures are tracked.

Refine release workflow before first publish

- Drop 'environment: maven-central' (we'll add manual-approval protection
  later; it required pre-creating the environment which would block the
  first run if forgotten).
- Switch GPG passphrase env var name to MAVEN_GPG_PASSPHRASE (the convention
  read by maven-gpg-plugin 3.x out of the box, no <passphraseServerId>
  configuration needed in the pom).