Greetings,
I was presented with the following scenario:
-
- A canton network’s acs is exported before maintenance event, which ends up corrupting the canton network without ways of fixing it.
- I create clone of the previous canton network and all its resources and wish to import the data exported earlier.
In this scenario I have these two different canton networks but they aren’t coexistent either one exists or the other, and never at the same time. Dars and parties migration is not a problem and I’m able to acquire the ids of several componets (parties, domains, participants, etc).
I’ve made some tests and was able to export the acs (relying on repair.export_acs command) of a source canton network with multiple participants to multiple compressed files (in gz type), but I’m struggling with importing it to the destined clone canton network. When attempting the latter I’m trying to adjust the party Ids which share the same hint but have different suffixes (id after ‘::’), as well as the domain Id which has the same alias.
After adjusting a file by modifying it as a gz stream making the necessary replacements I attemp to import the resulting acs as a temporary file (relying on repair.import_acs) but get error messages on the import command due to either one of the following messages:
- “Protocal message had invalid UTF-8”
- “While parsing a protocol message, the input ended unexpectedly in the middle of a field. This could mean either that the input has been truncated or that an embedded message misreported its own length.”
Both canton networks are runnning a Linux environment the exported acs seem to have been exported in ANSI enconding as far as I could understanding by default. The script I’m running is also in ANSI enconding so I’m not entirely sure if this is a script or data encoding issue or some issue with the import_acs command.
I would appreciate any suggestions on how to manage this scenario (by adjusting the script in some way for example). I’m not really aware of any other way of approaching this rather than exporting and importing a dump of the participants database.
Best Regards,
João Palma Santos