Dev tax service

[tzin1401]

No description provided.

[bitdive-review]

BitDive Runtime Review - PR #1579

PR: #1579
Branch: dev_tax_service -> main
Method: BitDive runtime trace comparison + direct HTTP verification + targeted code inspection
Verdict: REQUEST CHANGES
Confidence: High for the payment deployment blocker and checked stable service paths

Summary

PR 1579 changes payment Liquibase data changesets (changelog-0001-provider.sql, changelog-0002-provider.sql) to rename is_enabled → enabled in INSERT statements, aligning with the DDL column rename in changelog-0004.sql. It also adds PaymentPaypalApplication.java (compile-only in this review) and a trivial tax config comment.

Critical finding: both SQL files are already-applied changesets modified without runOnChange:true or validCheckSum:any. On any database where they ran before, Liquibase fails at payment startup:

ValidationFailedException: Validation Failed: 2 changesets check sum

Runtime result: payment 502 Bad Gateway on HEAD — service does not start. Baseline payment works (200, PAYPAL + COD providers).

Stable on HEAD: product list, location countries, and customer guest-user show zero contract divergence (TRACE_VERIFIED). CustomerService.java is not modified by this PR — an earlier review plan incorrectly assumed a guest-password change from a different branch.

Runtime Verification Matrix

Area	Result	Before PR	After PR	Evidence
Payment providers list	Blocked (regression)	200, PAYPAL + COD	502 — service fails Liquibase startup	before / after: no trace (startup crash)
Product listing	Stable	200, 4 trace nodes	200, zero contract drift	before / after
Location countries list	Stable	200, 249 trace nodes	200, zero divergence	before / after
Guest user create	Stable (unchanged code)	200, password GUEST	200, password GUEST (email random only)	before / after
Guest Keycloak auth	Stable	200, token issued	200, token issued	HTTP-only (Keycloak not traced)

Review scope and validation coverage

storefront / backoffice
  -> payment
     -> PaymentProviderController.getAll()     [BLOCKED — Liquibase checksum failure on HEAD]
  -> product
     -> ProductController.getProductsByMultiQuery()   [stable canary]
  -> location
     -> CountryStorefrontController.listCountries()    [stable]
  -> customer
     -> CustomerController.createGuestUser()           [stable — NOT changed by this PR]
  -> Keycloak token endpoint                            [HTTP only]

Behavior	Evidence	Status
Payment SQL migration	Git diff + baseline trace + HEAD 502	Merge blocker
Product list	Trace pair	Stable
Location countries	Trace pair	Stable
Guest user create	Trace pair + git diff (0 lines in CustomerService)	Stable, code unchanged
Guest auth	HTTP	Stable
PaymentPaypalApplication	Compile only	Not runtime-tested

Out of scope: CI/CD, frontend, tax application.properties comment-only change.

Change #1 — Liquibase checksum failure blocks payment startup

Files:

• payment/src/main/resources/db/changelog/data/changelog-0001-provider.sql (::paypal)
• payment/src/main/resources/db/changelog/data/changelog-0002-provider.sql (::cod)

Both changesets rename is_enabled → enabled in INSERT statements. The DDL rename (changelog-0004.sql) already applied the column change; this PR edits historical data changesets instead of adding new ones.

Runtime evidence

Side	HTTP	Service state
Before PR	200	Payment starts; providers PAYPAL + COD returned in 44ms
After PR	502	ValidationFailedException — 2 changeset checksum mismatches at startup

Baseline trace

before — 200, SQL uses enabled column, pre-existing ClassCastException in MediaService.getMediaVmMap() with working fallback (unrelated to PR).

Required fix

Add runOnChange:true or validCheckSum:any to both modified changesets, or create new migration changesets instead of editing already-applied ones.

Change #2 — stable services (no collateral regression)

Customer: CustomerService.java has zero diff in this PR. Trace pair shows identical 4-node topology; only guest email differs per invocation. Password remains GUEST on both sides (HTTP-verified).

Product: 4 nodes, 3 SQL both sides — timestamp-only divergence in MediaService.getMedia() headers.

Location: 249 nodes, 1 SQL both sides — zero divergence.

Limitations

Item	Notes
PaymentPaypalApplication	New module compiles; not in docker-compose — boot path untested
Payment after-trace	Impossible — service crashes during Spring/Liquibase init
Pre-existing MediaService ClassCastException	On payment baseline only; fallback works; not PR-caused
mergeStateStatus=BLOCKED	Branch protection — human action to merge

Follow-Ups

Type	Item	Blocking
Merge blocker	Fix Liquibase checksum conflict on payment data changesets	Yes
Non-blocking	Runtime-test PaymentPaypalApplication if module is intended for deploy	No
Informational	GitHub branch protection	No

Recommendation

Do not merge until the Liquibase issue is fixed. The column rename direction is correct (enabled matches DDL + JPA entity), but editing already-applied changesets without checksum handling breaks payment on existing databases. Product, location, and customer paths show no behavioral regression.