Skip to content

feat(share): move existing shares into dfo-apis with a migration job - #86

Merged
jm-rivera merged 1 commit into
devfrom
feat/share-migrate-job
Oct 29, 2026
Merged

jm-rivera merged 1 commit into
devfrom
feat/share-migrate-job

Conversation

@jm-rivera

Copy link
Copy Markdown
Contributor

The website's shares made before website#77 live in its own share table, and dfo-apis now serves every share, so their /s/<id> and /embed/<id> links answer 404 until they move. The export and import scripts written for that move could not run in a deployed environment: Cloud SQL is reachable only inside the private network, the import read a local file and wrote a local token report, and the website image shipped no scripts. This PR replaces them with a Cloud Run job, dist/migrate-shares.cjs, that runs inside the network.

migrateShares (db/share-migrate.ts) reads every share row with readShares, places it with the export's rules (db/share-export.ts, unchanged), and calls PUT /api/presentation/shares/{id}/import on dfo-apis with the line and write_token_sha256. For an owned share it runs two transactions. The first reads the owner's token in share_token or mints one and stores it with putShareToken, and commits, so a re-run reuses it. The second reads it with holdShareToken (src/lib/chat/shareTokens.ts), which holds the owner's user row FOR SHARE across the call, the lock putShareToken relies on, so an account deletion either waits and then takes the imported share down or lands first and the job skips the share (owner_deleted). Only the digest leaves the website. A guest share sends a null digest. Each refusal prints share <id>: <code> <detail>, a tally follows, and the job exits 1 when any share did not import or answer unchanged.

apisFetch signs a request when CLOUD_RUN_JOB is set as well as K_SERVICE, so the job calls dfo-apis with an ID token as the service does. The deploy workflow points SHARE_MIGRATE_JOB_WEBSITE at each release image and now requires that variable, which scripts/handoff.sh <env> website in DevelopmentFinanceObservatory/infra writes once infra#129 has applied there. A prod deploy of this change therefore waits on infra#129 reaching prod. CI builds the bundle and checks it fails naming its first missing setting. scripts/export-shares.ts, scripts/import-share-tokens.ts and db/share-token-import.ts are removed, and docs/share-export.md and deploy/README.md describe the job.

The job, and dfo-apis' import route and principal, exist for one migration per environment and are removed once prod is migrated.

Testing: lint, lint:css, typecheck, pnpm test against Postgres 18 (2,171 passed), and every bundle build. The new tests cover a guest share, minting once and reusing on a re-run, the lock held during the call (a fence update times out with 55P03), a fenced or deleted owner, the tally and exit code, and the HTTP mapping; each fails with its guard removed. The round trip against the dfo-apis local stack runs once the import route lands.

The share migration job reads the website's own share rows, places each
as the export did, keeps each owner's shw_ write token in share_token,
and calls dfo-apis' PUT /api/presentation/shares/{id}/import with only
the token's SHA-256. It holds the owner's user row FOR SHARE across the
call, so an account deletion either waits and takes the imported share
down or lands first and the job skips the share. The export and
token-import scripts are removed. apisFetch signs requests from a Cloud
Run job as well as a service, so the job calls dfo-apis with an ID token.
@jm-rivera
jm-rivera merged commit 2e0418a into dev Oct 29, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant