fix(authserver): sync prod + H2 profile defects discovered after PR #125#126
Merged
Conversation
PR #125 patched defects discovered while booting dev-mysql, but two of those patches needed to be propagated to other profiles to prevent the same bugs from biting elsewhere. Audit summarized at #122 Patch 1 — prod profile flyway.target=2.0.0 application-prod.yml uses MySQL vendor migrations, which means a first deploy against a clean prod DB would hit the same V3 schema drift that #125 patched on dev-mysql ("Unknown column 'client_description'"). Added the same target=2.0.0 workaround with a pointer to #123. Will be removed once #123 lands. Patch 2 — H2 V1 UNIQUE on oauth2_registered_client.client_id H2 V1 schema had only PRIMARY KEY (id) on oauth2_registered_client, no unique constraint on client_id. Not blocking H2 boot today (H2's espi_application_info table doesn't declare an FK referencing it), but client_id is unique by OAuth2 semantics and MySQL/PostgreSQL V1 both enforce uniqueness. Added UNIQUE constraint and removed the now-redundant non-unique CREATE INDEX, mirroring the MySQL cleanup from #125. Audited but no change needed - HikariCP auto-commit (patch #6 from #125): dev-postgresql, local, prod, and docker all rely on the HikariCP default (true). The dev-mysql auto-commit: false was an outlier bug, not a shared default. - PostgreSQL V3 INSERT: PostgreSQL V1 already has the columns V3 targets (client_description, contact_*, scope, grant_types, response_types). Different drift pattern from MySQL — no target=2.0.0 workaround needed on dev-postgresql at this time. (V4-V6 drift TBD as part of #123.) Refs: #122 #123 #125 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #125. Propagates two patches from that PR to the profiles where the same defects exist but weren't directly observed during the dev-mysql boot session. Cross-profile audit summarized at #122 comment.
Changes
1.
application-prod.yml— addflyway.target: "2.0.0"workaround for #123Prod uses MySQL vendor migrations (
classpath:db/vendor/mysql). A first deploy against a clean prod DB would die at V3 withUnknown column 'client_description'— identical to the dev-mysql failure that #125 patched. Without this fix, prod is a latent landmine waiting for someone to migrate a fresh database.This is a temporary workaround — removed once #123 (ESPI 4.0 XSD-aligned schema repair) lands.
2. H2 V1 — add
UNIQUEconstraint onoauth2_registered_client.client_idH2 V1 schema had only
PRIMARY KEY (id)onoauth2_registered_clientand a non-uniqueCREATE INDEXonclient_id, while MySQL V1 (after #125) and PostgreSQL V1 (already correct) both enforce uniqueness on that column.client_idis unique by OAuth2 semantics; the inconsistency invites future bugs (e.g., if anyone adds an FK referencing this column in H2 later, they'd hit the same MySQL bug #125 fixed).Not blocking H2 boot today — H2's
espi_application_infotable doesn't declare an FK againstoauth2_registered_client.client_id, so the absence of UNIQUE isn't a CREATE TABLE error. This change closes the consistency gap. Also removed the now-redundant non-uniqueCREATE INDEX, mirroring the MySQL cleanup from #125.Audited and no change needed
auto-commit: true)dev-postgresql,local,prod,docker-composeall rely on the HikariCP default (true). Thedev-mysqlauto-commit: falsewas an outlier bug, not a shared default.db/vendor/postgresql/V1_0_0:79-119) already declaresclient_description,contact_*,scope,grant_types,response_types— different drift pattern from MySQL.dev-postgresqldoesn't needtarget=2.0.0at this time. V4-V6 drift is part of #123's audit scope.Diff
Test plan
git diffreviewed for both fileslocalprofile boot is its own work item); the H2 change is architectural-consistency onlyRelated
target: "2.0.0"workaround when it lands)🤖 Generated with Claude Code