Skip to content

feat(harness): keep account keys between deploys - #312

Merged
luchobonatti merged 4 commits into
mainfrom
feat/309-keep-harness-keys
Oct 22, 2026
Merged

luchobonatti merged 4 commits into
mainfrom
feat/309-keep-harness-keys

Conversation

@hpmaxi

@hpmaxi hpmaxi commented Oct 22, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Closes #309

Every deploy made new random keys for the thirteen harness accounts and kept
them only in deployed.<network>.json, which the next deploy overwrote. That
lost every key of a testnet deployment. Keys now live in their own file, which
deploys read and complete but never replace, and old records are kept.

Changes

  • Deploys read account keys from a per-network file, add only missing ones, and write it (mode 0600) before any transaction.
  • npm run keys creates or completes that file without deploying and prints public keys only.
  • Funding skips accounts that already exist, on both funding paths.
  • A new deploy keeps the previous record under its deployment time.
  • Keys files and old records stay out of git; the harness README explains them.

Deviations

  • A deploy reuses the issuer's existing asset contract. Without it, a second deploy with kept keys fails right after funding (contract already exists).
  • The keys file also refuses an account set twice, or one key for two accounts.
  • The root npm run test now runs the harness unit tests, so CI does.

Acceptance criteria

  • A deploy reads each account's secret from .env.keys.<network> at the repository root, creates and saves only the missing ones before any transaction, and never replaces an existing one
  • npm run keys creates or completes the file without deploying, and prints the public keys only
  • A deploy whose accounts already exist on the network does not fail at funding
  • A new deploy keeps the previous record as deployed.<network>.<timestamp>.json instead of overwriting it
  • The key files and old records stay out of git, and the harness README says where the keys live and that they must be backed up

Test plan

Automated tests

  1. npm run test:unit -w scripts/harness: 4 files, 17 tests pass, no network.
  2. npm run test: 76 files, 1725 tests pass, the harness unit tests included.
  3. npm run lint -w scripts/harness and npm run typecheck -w scripts/harness: no errors (typecheck after npm run build:clients).
  4. npm run format:check: clean.

CI's build job fails on every PR since 2026-10-22: the newest quickstart image moves the local network to protocol 30, where the current CLI cannot deploy. Pinning the local network to protocol 29 fixes it; that change waits for a push with the workflow scope.

Manual verification

  1. Start a local network: docker run --rm -d -p 8000:8000 --name stellar-local stellar/quickstart:v678-b1525.1-latest --local --enable core,rpc.
  2. HARNESS_NETWORK=local npm run deploy -w scripts/harness: account keys in .env.keys.local (13 new), funded 13 accounts; 0 already existed. The file is -rw-------.
  3. HARNESS_NETWORK=local npm run keys -w scripts/harness: (0 new) and thirteen public keys, no secret.
  4. Deploy again: (0 new), funded 0 accounts; 13 already existed, the same asset contract, new vault contracts, and kept the previous record as deployed.local.2026-10-22T13-37-20-150Z.json.
  5. Both records list the same public keys as step 3, and test:happy-path (24 tests) and test:guards (37 tests) pass against the second deployment.

Breaking changes

None.

Checklist

  • Self-reviewed my own diff
  • Tests added or updated
  • Docs updated (if applicable)
  • No unrelated changes bundled in

Screenshots

None.

Every deploy made new random keys for the thirteen harness accounts and
kept them only in deployed.<network>.json, which the next deploy
overwrote.

A deploy now reads the keys from scripts/harness/.env.keys.<network>,
adds a key only for an account without one, and writes the file with
mode 0600 before any transaction. `npm run keys` does the same without
deploying and prints public keys only. Funding skips accounts that
already exist, the issuer's existing asset contract is reused, and the
previous record is kept as deployed.<network>.<timestamp>.json.

The harness unit tests need no network and run in the root test run.
@vercel

vercel Bot commented Oct 22, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
strata-vault-kit-app Ready Ready Preview Oct 22, 2026 6:56pm UTC

Request Review

Env files usually live at the root, where they are easier to find, and
the root .gitignore already ignores them.
}
}

async function exists(server: rpc.Server, publicKey: string): Promise<boolean> {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exists() treats any RPC error as a missing account, so a timeout ends in a confusing "already exists" at funding. Maybe return false only on "Account not found" and rethrow the rest?

Comment thread scripts/harness/deploy.ts
) as Deployment["accounts"],
}
saveDeployment(record)
const kept = saveDeployment(record)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The record still carries every secret (line 243) and each deploy now keeps another 0644 copy. With the keys file as the source of truth, maybe store public keys only, or write the records 0600?

@luchobonatti
luchobonatti merged commit 26c33a6 into main Oct 22, 2026
3 checks passed
@luchobonatti
luchobonatti deleted the feat/309-keep-harness-keys branch October 22, 2026 19:17

This branch was successfully deployed

1 active deployment
Preview — a1898e1c Deployed Oct 22, 2026 by vercel[bot]
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.

Keep the harness's account keys between deploys

2 participants