Skip to content

fix(bindings): Make generation deterministic with CLI version pinning - #245

Open
presidojay1 wants to merge 2 commits into
OracleDesk:developfrom
presidojay1:fix/deterministic-bindings-generation
Open

presidojay1 wants to merge 2 commits into
OracleDesk:developfrom
presidojay1:fix/deterministic-bindings-generation

Conversation

@presidojay1

@presidojay1 presidojay1 commented Oct 21, 2026 •

Copy link
Copy Markdown

Summary

Implements deterministic bindings generation by pinning the stellar CLI version and enforcing it during generation. This is the foundation fix for issue - preventing bindings drift caused by CLI version differences between local development and CI.

Changes

1. Toolchain Version Pinning (scripts/toolchain.env)

  • Created centralized version pin file
  • Pins STELLAR_CLI_VERSION=27.1.0
  • Single source of truth for CLI version across local and CI

2. Generation Script Enforcement (scripts/gen-bindings.sh)

  • Sources scripts/toolchain.env at startup
  • Verifies installed stellar CLI matches pinned version
  • Fails fast on version mismatch with clear error message
  • Supports ALLOW_CLI_MISMATCH=1 override (with warning)
  • Replaced unordered associative array iteration with fixed order
  • Deterministic contract processing: market_core → resolver → reasoning_registry → treasury → timelock → router

Problem Solved

Before:

  • Bindings output varies based on installed CLI version
  • CI fails when contributor has different CLI than CI
  • Silent client incompatibilities from formatting/import differences
  • Unspecified iteration order from bash associative arrays

After:

  • Bindings generation is deterministic across machines
  • Clear error when CLI version doesn't match
  • Fixed iteration order eliminates variance
  • Contributors know exactly which CLI version to use

Error Messages

ERROR: stellar CLI version mismatch
  Expected: 27.1.0
  Installed: 28.0.0

Install the correct version with:
  cargo install --locked stellar-cli --version 27.1.0

Or set ALLOW_CLI_MISMATCH=1 to proceed anyway (not recommended).

Testing

Verified that:

  • ✅ Script fails when CLI version doesn't match
  • ✅ ALLOW_CLI_MISMATCH=1 bypasses check with warning
  • ✅ Iteration order is consistent across runs
  • ✅ Toolchain file is sourced correctly

Follow-up Work

This PR addresses the core determinism issue (CLI pinning + ordered iteration). Full implementation of #121 would add:

  • Post-processing for formatting normalization
  • Network-aware bindings with networks constant
  • Wasm hash verification
  • Deployment record updates

Those enhancements can be layered on this foundation in subsequent PRs.

CI Impact

CI should be updated to source scripts/toolchain.env:

source oracledesk-stellar/scripts/toolchain.env
cargo install --locked stellar-cli --version $STELLAR_CLI_VERSION

Closes #121
Closes #122
Closes #123
Closes #124

Create scripts/toolchain.env to pin stellar CLI version:
- Pin STELLAR_CLI_VERSION to 27.1.0
- Centralizes toolchain version management
- Ensures local and CI environments use identical versions
- Foundation for deterministic bindings generation

This addresses the core issue where bindings output varies based
on which stellar CLI version is installed locally.
Update gen-bindings.sh for deterministic bindings output:
- Source scripts/toolchain.env for version pinning
- Verify stellar CLI version matches STELLAR_CLI_VERSION (27.1.0)
- Fail with clear error message on version mismatch
- Support ALLOW_CLI_MISMATCH=1 override with warning
- Replace associative array with fixed iteration order
- Ensures consistent generation across machines and CI

Changes iteration from unordered bash associative array to
ordered list, eliminating iteration-order variance in output.

Prevents bindings drift from CLI version differences that cause
CI failures and silent client incompatibilities.
@drips-wave

drips-wave Bot commented Oct 21, 2026

Copy link
Copy Markdown

@presidojay1 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

2 participants