Skip to content

fix(plugin): encode plugin requests deterministically - #244

Merged
Yakwilik merged 1 commit into
easyp-tech:mainfrom
yaroher:fix/deterministic-plugin-request
Oct 26, 2026
Merged

Yakwilik merged 1 commit into
easyp-tech:mainfrom
yaroher:fix/deterministic-plugin-request

Conversation

@yaroher

@yaroher yaroher commented Oct 22, 2026

Copy link
Copy Markdown
Contributor

Fixes #243.

The command, local and builtin executors now encode CodeGeneratorRequest through one helper that sets Deterministic: true, which is what descriptor set output already does.

Checked two ways. TestMarshalRequestIsDeterministic compiles a file with message-typed custom options and encodes the request 100 times; it fails on plain proto.Marshal. Then I ran easyp generate 20 times against a local plugin that dumps its stdin: current main produced 5 distinct requests, this branch produced 1.

The remote executor goes through gRPC's codec and isn't changed here.

- custom options are dynamic messages; plain proto.Marshal orders
  their fields randomly, so plugins that embed descriptors (es)
  produced different output on every run
- route command, local and builtin executors through marshalRequest

Fixes easyp-tech#243
@Yakwilik
Yakwilik self-requested a review October 22, 2026 15:11
@Yakwilik
Yakwilik merged commit 61d2abd into easyp-tech:main Oct 26, 2026
2 checks 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.

Plugin request encoding is non-deterministic, generated code changes between runs

2 participants