Skip to content

fix(ledgrpc): align ImportPartyAcsRequest with Canton 3.5.3 - #21

Open
schronck wants to merge 1 commit into
mainfrom
fix/import-party-acs-canton-3.5.3
Open

fix(ledgrpc): align ImportPartyAcsRequest with Canton 3.5.3#21
schronck wants to merge 1 commit into
mainfrom
fix/import-party-acs-canton-3.5.3

Conversation

@schronck

Copy link
Copy Markdown
Contributor

Problem

Canton 3.5 changed ImportPartyAcsRequest: it inserted synchronizer_id (field 2) and party_id (field 6), made the existing fields optional, and shifted workflow_id_prefix → 3, contract_import_mode → 4, representative_package_id_override → 5. Our vendored proto still has the 3.4 layout (workflow_id_prefix at field 2). A client built against 3.4 sends its workflow prefix in field 2, which a 3.5 node decodes as synchronizer_id and rejects:

INVALID_ARGUMENT_PARTY_MANAGEMENT_ERROR(8,0): Unable to convert field `synchronizer_id`:
Invalid unique identifier `add-party-acs-import` with missing namespace.

(Reproduced from dec-party-manager's add-party / offline party replication flow against a devnet participant.)

Fix

Refreshed ImportPartyAcsRequest to the Canton 3.5.3 shape, verified field-by-field via gRPC reflection against a live 3.5.3 participant:

acs_snapshot=1, synchronizer_id=2 (new), workflow_id_prefix=3,
contract_import_mode=4, representative_package_id_override=5, party_id=6 (new)

This is the only message in the party-management admin API that drifted between 3.4 and 3.5.3 for our call set — ExportPartyAcsRequest, ClearPartyOnboardingFlagRequest, and GetHighestOffsetByTimestampRequest all still match (confirmed via the same reflection check), so the blast radius is one message.

Crate version 3.4.03.5.3 to reflect the targeted Canton version.

🤖 Generated with Claude Code

Canton 3.5 inserted synchronizer_id (field 2) and party_id (field 6) into
ImportPartyAcsRequest and made the existing fields optional, shifting
workflow_id_prefix/contract_import_mode/representative_package_id_override
down by one. Clients built against the 3.4 layout send workflow_id_prefix in
field 2, which 3.5 nodes decode as synchronizer_id and reject. Refreshed the
message to the 3.5.3 shape (verified via gRPC reflection against a live 3.5.3
participant). Only this message changed in the party-management API surface.
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