Skip to content

refactor(typescript): remove orphaned GetSecret/SetSecret delegate types#78

Merged
sanity merged 2 commits into
mainfrom
cleanup/remove-stale-delegate-secret-types
Jun 1, 2026
Merged

refactor(typescript): remove orphaned GetSecret/SetSecret delegate types#78
sanity merged 2 commits into
mainfrom
cleanup/remove-stale-delegate-secret-types

Conversation

@sanity
Copy link
Copy Markdown
Contributor

@sanity sanity commented Jun 1, 2026

Problem

The TypeScript SDK ships six flatc-generated files for delegate secret-store messages, GetSecretRequest / GetSecretResponse / SetSecretRequest, that no longer correspond to anything:

  • No matching table exists in any schemas/flatbuffers/*.fbs (the shared wire contract).
  • The Rust client API removed these message types entirely (grep -rn "GetSecretRequest\|SetSecretRequest\|GetSecretResponse" rust/src/ → none).

flatc never deletes the generated file when a table is removed from a schema, so these lingered as dead, misleading public exports. The DelegateRequest constructor union even advertised a GetSecretRequestType variant that the underlying flatbuffer DelegateRequestType union (ApplicationMessages | RegisterDelegate | UnregisterDelegate) cannot represent.

This is the only delegate-API drift between the TS SDK and Rust: the client-side delegate surface (register / unregister / application-messages + response decoding) is otherwise at parity (done in #67). The newer Rust delegate variants (GetContractRequest, SendDelegateMessage, etc.) are part of the delegate runtime interface (host↔WASM), which Rust explicitly forbids from reaching client serialization, so the TS client SDK correctly does not implement them.

Approach

Surgical removal of dead generated code, not a flatc regen:

  • Delete the 6 orphaned generated files.
  • Remove their imports and public type re-exports from websocket-interface.ts.
  • Drop the impossible GetSecretRequestType member from the DelegateRequest constructor union.

SecretsId is intentionally kept — its table still exists in common.fbs and is used by the Rust delegate runtime (delegate_interface.rs), so it is live, not orphaned.

I deliberately did not run npm run flatc-schemas: the installed flatc is 24.3.25 while the runtime lib is pinned to ^25.9.23, so a regen would rewrite every generated file with a noisy, possibly incompatible diff (cf. #73, which reverted exactly such an accidental regen). Surgical deletion is equivalent for orphan tables and keeps the diff minimal.

No wire-format change: schemas/flatbuffers/*.fbs and all Rust code are untouched.

Testing

  • npm run build (tsc): clean.
  • npm test: all 52 jest tests pass (3 suites, including delegates-and-responses.test.ts).
  • Confirmed zero remaining references to the removed types in src/ and tests/.

[AI-assisted - Claude]

sanity and others added 2 commits June 1, 2026 16:06
These flatc-generated files correspond to delegate secret-store messages
(GetSecretRequest, GetSecretResponse, SetSecretRequest) that no longer exist
in any flatbuffer schema or in the Rust client API. flatc never deletes the
generated file when a table is removed from a .fbs, so they lingered as dead,
misleading exports in the published SDK.

- Delete 6 orphaned generated files (no matching table in
  schemas/flatbuffers/*.fbs).
- Remove their imports and public type re-exports from websocket-interface.ts.
- Drop the impossible GetSecretRequestType member from the DelegateRequest
  constructor union, leaving the schema's actual variants
  (ApplicationMessages | RegisterDelegate | UnregisterDelegate).

SecretsId is intentionally kept: its table still exists in common.fbs and is
used by the Rust delegate runtime (delegate_interface.rs).

No wire-format change: schemas/flatbuffers/*.fbs and all Rust code are
untouched. tsc build is clean and all 52 jest tests pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Address review (PR #78): host-response/random-bytes-request.ts is the only
other orphaned flatc-generated file of the same class as the GetSecret/SetSecret
removals. RandomBytesRequest has no table in any schemas/flatbuffers/*.fbs (the
live host-response random-data table is GenerateRandData, with its own
generate-rand-data.ts), no reference in rust/src/, and is not imported or
re-exported by any barrel, websocket-interface.ts, or index.ts. An exhaustive
sweep of every generated file under client-request/, common/, and host-response/
against the schema confirms this is the last remaining orphan, so the cleanup
is now complete.

Verified: re-running flatc against the live schemas regenerates none of these
files. tsc build clean; all 52 jest tests pass.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown
Contributor Author

@sanity sanity left a comment

Choose a reason for hiding this comment

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

Comprehensive PR Review: #78

Summary

  • PR Title: refactor(typescript): remove orphaned GetSecret/SetSecret delegate types
  • Type: refactor (dead-code removal)
  • CI Status: ✅ green on HEAD a2987af (all required checks SUCCESS)
  • Linked Issues: none
  • Review tier: Light (pure deletion of orphaned flatc-generated TS; no .fbs/Rust/wire change)
  • Reviewers run: code-first, skeptical, big-picture (Claude) + Codex (GPT-5.5, external) — re-run on final HEAD

Code-First Analysis

Independent understanding: Deletes 7 flatc-generated TS files whose flatbuffer tables no longer exist in any schema, and removes their imports/@public type aliases + the impossible GetSecretRequestType member of the DelegateRequest constructor union from websocket-interface.ts.
Alignment: Matches stated intent exactly — 0 additions / 910 deletions, .fbs and Rust untouched. tsc --noEmit passes; no dangling references.

Testing Assessment

Test Type Status Notes
Unit/SDK 52/52 jest tests pass (incl. delegates-and-responses.test.ts)
Build tsc clean

Deletion-only change of dead code with no backing wire table; no new tests warranted.

Skeptical Findings

Risk: low. The decisive check: reviewer ran flatc --ts --gen-object-api against the live schemas — none of the deleted files regenerate; the only secret-related output is common/secrets-id.ts (kept). Repo-wide grep: zero remaining references. No Must/Should-Fix.

Big Picture Assessment

Goal alignment: yes. One Should-Fix raised and resolved in a2987af: host-response/random-bytes-request.ts was another orphan of the identical class (no RandomBytesRequest table — the live one is GenerateRandData; no Rust ref; not re-exported by any barrel). An exhaustive sweep of every generated file under client-request/, common/, host-response/ against the schema confirms it was the last remaining orphan, so the cleanup is now complete.
TS↔Rust↔fbs alignment: DelegateRequest = ApplicationMessages | RegisterDelegate | UnregisterDelegate across all three (client_events.rs:567, client_request.fbs:108, edited TS union). SecretsId correctly retained — still in common.fbs:12 and used by delegate_interface.rs:324.

Documentation

No README/example/comment referenced the removed types; nothing goes stale.

Recommendations

Must Fix: none.
Should Fix: none outstanding (the one finding was addressed in a2987af).
Consider: Removing the @public aliases is semver-breaking in principle for the npm package (pre-1.0; the types were non-functional). The accompanying release should bump @freenetorg/freenet-stdlib 0.2.0 → 0.3.0, published from main after merge.

Verdict

State: Ready to Merge
HEAD SHA reviewed: a2987af364292dfb2852456db6ec11281266f66f

[AI-assisted - Claude]

@sanity sanity merged commit 8c60cb6 into main Jun 1, 2026
10 checks passed
@sanity sanity deleted the cleanup/remove-stale-delegate-secret-types branch June 1, 2026 21:18
sanity added a commit that referenced this pull request Jun 2, 2026
Bump @freenetorg/freenet-stdlib 0.2.0 -> 0.3.0 for the #78 delegate type cleanup. [AI-assisted - Claude]
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