Skip to content

refact: wasm compatibility#18

Open
schronck wants to merge 3 commits into
mainfrom
refact/wasm
Open

refact: wasm compatibility#18
schronck wants to merge 3 commits into
mainfrom
refact/wasm

Conversation

@schronck
Copy link
Copy Markdown

@schronck schronck commented Feb 9, 2026

No description provided.

@schronck schronck self-assigned this Feb 9, 2026
@schronck schronck requested a review from sosaucily February 9, 2026 09:42
Comment thread Cargo.toml Outdated
Comment thread src/transfer.rs Outdated
Comment thread src/lib.rs Outdated

// Modules that require file I/O - only available on native targets
#[cfg(not(target_arch = "wasm32"))]
pub mod batch;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

so batching isn't available with wasm? why is that?

i guess this PR will require updates to the readme when it's finalized

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Currently, the problem with the batch module is that we are using the csv::Reader::from_path, but I think we can solve this by hiding only the file reading stuff behind the flag and for WASM add a parse function which will get the content of the csv from somewhere...

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

Pushed a fix for this

@sosaucily
Copy link
Copy Markdown
Contributor

generally i would like to see less wasm-specific logic if possible. even if it means doing things in a slightly more complicated way.

@schronck
Copy link
Copy Markdown
Author

We should eliminate all environment variable reads from the codebase because it’s generally a poor pattern. Environment variables are process-level configuration and should be read once at program startup (or at a clearly defined boundary) and then passed down explicitly as arguments (or via a config object / dependency injection). This makes behavior deterministic, improves testability, and avoids hidden global dependencies.

On UNIX-like systems (Linux, Darwin/macOS), an application receives its environment at process creation time: the parent passes an environment array into execve(), and a fork() creates a copy for the child. After the process has started, other processes cannot modify its environment; only the process itself (or code running inside it) can change it via setenv()/unsetenv() etc. So repeatedly calling getenv() during runtime rarely provides any meaningful “freshness,” and in multi-threaded code it can introduce subtle races if any thread mutates the environment.

(which is another reason to treat environment variables as immutable startup configuration and to avoid reading them from within library code...)

gyorgybalazsi added a commit that referenced this pull request May 19, 2026
Replaces the temporary branch refs (`branch =
"chore/bump-canton-api-client-3.6.0"`) on `ledger`/`keycloak`/`registry`/
`common` with `tag = "v0.6.0"`. canton-lib v0.6.0 (DLC-link/canton-lib#20)
contains the 3.6.0 bump (#18) plus the keycloak Quarkus token-URL helpers
(#19); the upstream PR branch was deleted on merge, so the previous refs no
longer resolve.

Cargo.lock updated by `cargo update -p ledger -p keycloak -p registry -p
common`. `cargo check` clean.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
schronck pushed a commit that referenced this pull request May 19, 2026
* chore: bump canton-api-client to 3.6.0-0.1.0

Note: this PR also requires a new canton-lib tag containing the same
canton-api-client bump in its `common` crate. Blocked on
DLC-link/canton-lib#18 and the follow-up release.

* chore: adapt to canton-api-client 3.6.0 spec changes

Adapts cbtc-lib to the spec deltas introduced in Canton 3.6.0 — many
previously required fields are now optional, `create_argument` is no
longer double-wrapped (`Option<Option<Value>>` → `Option<Value>`),
`transaction.events` and `package_ids` are now required (no longer
`Option<Vec>`), `created_event_blob` is now `Option<String>`,
`CreatedEvent` gained required `representativePackageId`/`acsDelta`
fields, and `ExercisedEvent` gained `acsDelta`.

Mechanical changes:

- accept/cancel_offers/utils/list_incoming_offers/list_outgoing_offers:
  drop the outer `Some(...)` from `if let Some(Some(create_arg)) = ...`
  patterns on `create_argument`.
- credentials/mint_redeem/models: drop the
  `.and_then(|opt| opt.as_ref())` middle step from the
  `create_argument.as_ref().and_then(...).and_then(|v| v.as_object())`
  chains used to read the create-argument map.
- credentials/mint_redeem/models: `created_event.created_event_blob` is
  now `Option<String>`; `unwrap_or_default()` to preserve the existing
  `String` surface on the local types.
- consolidate/split/transfer/mint_redeem/credentials parsers:
  `transaction.events` is no longer `Option<Vec<Event>>`; drop the
  `.as_ref().ok_or("Failed to find events")?` indirection and iterate
  the Vec directly.
- consolidate/split/transfer parsers: `ExercisedEvent.exercise_result`
  is `Option<Option<Value>>` in 3.6 — match `Some(Some(result))` rather
  than the single-layer pattern that used to compile against 3.3.
- dar_check: `ListPackagesResponse.package_ids` is now a plain
  `Vec<String>`; drop the `.ok_or_else(...)` that handled the previous
  optional wrapping.
- utils test fixtures: include the new required
  `representativePackageId`/`acsDelta` fields on `CreatedEvent`,
  `acsDelta` on `ExercisedEvent`, and always emit `events: []` (rather
  than omitting the field) since `JsTransaction.events` is required.
- parser unit tests for the "missing events" case: update assertions to
  the new error messages each parser returns when given an empty events
  list (the old "Failed to find events" branch no longer exists, since
  the typed model guarantees events is present).

NOTE: this commit temporarily points the four canton-lib deps at the
`chore/bump-canton-api-client-3.6.0` branch so the workspace can
resolve end-to-end against the matching canton-api-client 3.6.0 bump
there. The maintainer should swap these back to a real v0.6.0 tag
before merging.

* fix(integration_test): filter holdings to CBTC before splitting

The step 20 split called `holdings.first()` on the result of
`list_holdings`, which returns every Holding-template contract owned by
the party. On devnet the sender's account holds legacy `CBTCV0RC8`
instrument holdings alongside `CBTC`, so `.first()` could pick a
non-CBTC holding. The split request then asserted `instrument_id = "CBTC"`,
and the registry correctly rejected the mismatch with 400 "Given holdings
are invalid".

Filter to `instrument_id == "CBTC"` before picking, matching the pattern
already used by `submit_withdraw` in `mint_redeem::redeem`.

Verified end-to-end on devnet: 20/20 integration_test steps pass.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* chore: pin canton-lib deps to v0.6.0 tag

Replaces the temporary branch refs (`branch =
"chore/bump-canton-api-client-3.6.0"`) on `ledger`/`keycloak`/`registry`/
`common` with `tag = "v0.6.0"`. canton-lib v0.6.0 (DLC-link/canton-lib#20)
contains the 3.6.0 bump (#18) plus the keycloak Quarkus token-URL helpers
(#19); the upstream PR branch was deleted on merge, so the previous refs no
longer resolve.

Cargo.lock updated by `cargo update -p ledger -p keycloak -p registry -p
common`. `cargo check` clean.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* chore: bump cbtc version to 0.6.0

Aligns cbtc-lib's crate version with the canton-lib v0.6.0 release this
PR depends on. Skips 0.5.x — the version jump reflects the canton-api-client
3.6.0 wire bump pulled in transitively (breaking change in dependency
behavior, see CHANGELOG of canton-lib v0.6.0 for the `ledger_end::get`
error-path change).

cbtc-lib's public API is unchanged.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: gyorgybalazsi <gyorgy.balazsi@gmail.com>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
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.

2 participants