fix: default personal_access_token.version and .type

[netomi]

Problem

V1_72__Trusted_Publisher.sql added personal_access_token.version and .type as NOT NULL with no default, so every INSERT into the table now has to name them. The bootstrap procedure documented for registries deployed without a login provider — deploy/kubernetes/README.md:197, and the wiki's Deleting Extensions page — fails outright on a current schema:

null value in column "version" of relation "personal_access_token" violates not-null constraint

The dev seed in server/src/dev/resources/db/migration/V1_0_1__Super_user.sql only still works because Flyway runs it before V1_72, which then backfills it.

Change

V1_74 defaults the two columns to exactly what V1_72's own backfill would have left behind, so an INSERT written against the pre-V1_72 schema still produces a working token.

version defaults to 0 — deliberately the oldest format, not the current one. The hash pepper lives in the application configuration and never reaches the database, so a value inserted by hand cannot be anything but plaintext; AccessTokenService#useAccessToken falls back to a plaintext lookup and hashes the row in place on first use, and the startup upgrade job does the same for tokens that are never used. The migration comment spells out that this must stay pinned at 0 rather than tracking TOKEN_CURRENT_VERSION, and that version 0 has to keep being understood by upgradeToken for as long as the default stands — raising it would make such a row read as an already-hashed value and silently never authenticate.

type defaults to LLT, the only type an operator would create by hand; OTT and TPT are issued by the server and carry state an INSERT omitting the type wouldn't be supplying either.

This can't mask a bug in the application's own inserts. PersonalAccessToken has @DynamicUpdate but not @DynamicInsert, so Hibernate lists every column on every insert — a code path that forgets setType still sends an explicit NULL and still fails on the constraint. The defaults are only ever reachable from hand-written SQL that omits the columns.

import-db-dump.sh

The script's gap detection keyed on is_nullable='NO' and column_default is null, which these two columns now stop matching — and with them KNOWN_BACKFILLS["personal_access_token.type"], the backfill that classifies pre-V1_72 one-time tokens as OTT by description. Without it they'd import as LLT, quietly turning a used-once credential into a permanent one.

Split the two things that check was conflating:

• every target column the dump lacks may carry a backfill, which runs after the \copy;
• only those that can't be imported at all (NOT NULL, no default) are required to have one, and only those get their NOT NULL dropped around the copy.

Testing

Exercised the rewritten detection against a scratch Postgres in three shapes:

target schema	REQUIRED_GAPS	BACKFILL_COLUMNS	UNKNOWN_GAPS
with the V1_74 defaults	–	version, type	–
V1_72/V1_73, no defaults	version, type	version, type	–
unregistered NOT NULL column	+ brand_new	version, type	brand_new (refused)

Newly-gained nullable columns (scope_extension_id, claims) are correctly ignored, and an older target still behaves exactly as before. Also ran the simulated import — dump-era column list, then the registered backfill — and confirmed a One time use publish token row still lands as OTT while the rest default to LLT at version = 0, and applied V1_74 itself against a post-V1_72 table.

Stale entity mapping

V1_72 also widened personal_access_token.value to 128 characters — the digest of whichever algorithm ovsx.access-token.token-hash-algorithm names need not be SHA-256's 64 hex characters — while PersonalAccessToken kept declaring @Column(length = 64). Nothing reads it under ddl-auto: none; it was just wrong about the schema it maps. Corrected, with a note on where the number comes from.

Wiki

The Deleting Extensions page documents the required columns in detail and needs the matching edit; that's prepared separately and not part of this PR.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

There are a couple of concrete correctness/robustness issues in the new migration/script comments/parsing that should be adjusted before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR addresses schema compatibility and operational tooling around personal_access_token after V1_72 introduced version and type as NOT NULL without defaults, which breaks older/manual INSERT workflows and the documented bootstrap procedure.

Changes:

• Adds Flyway migration V1_74 to default personal_access_token.version to 0 and personal_access_token.type to LLT to restore compatibility for INSERTs that omit these newer columns.
• Updates scripts/import-db-dump.sh gap detection to distinguish (1) columns that are truly un-importable without a backfill (NOT NULL + no default) from (2) columns that still need a backfill to preserve semantics even if a default exists.

File summaries

File	Description
server/src/main/resources/db/migration/V1_74__PersonalAccessToken_Column_Defaults.sql	Sets DB-level defaults for personal_access_token.version and .type to keep manual/older INSERTs working post-V1_72.
scripts/import-db-dump.sh	Refines dump import gap detection to run backfills for semantic correctness while only dropping NOT NULL when strictly required.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.