Cannot start local worker without initializing the shard

[kziemianek]

I tried to run local setup using local-setup/launch.py script but the worker panics during the initialization:

kziemianek@kziemianek:~/projects/integritee/worker/log$ cat worker1.log 
[2024-05-22T12:54:09.972625Z INFO  enclave_runtime] Setting base_dir to /tmp/data-dir
[2024-05-22T12:54:09.972934Z INFO  enclave_runtime::initialization] [Enclave initialized] Ed25519 prim raw : [144, 19, 76, 231, 123, 104, 8, 34, 138, 161, 172, 4, 101, 92, 28, 92, 37, 114, 238, 126, 203, 24, 238, 208, 20, 196, 194, 105, 131, 20, 198, 247]
[2024-05-22T12:54:10.026787Z DEBUG itp_stf_state_handler::state_snapshot_repository_loader] Found 0 shard(s) to load state from
[load_pce ../pce_wrapper.cpp:195] Error, call sgx_create_enclave for PCE fail [load_pce], SGXError:200e.
[2024-05-22T12:54:10.033Z WARN  integritee_service::main_impl] Setting up DCAP - qe_get_target_info failed with error: SgxQuote(SGX_QL_INTERFACE_UNAVAILABLE), continuing.
[load_pce ../pce_wrapper.cpp:195] Error, call sgx_create_enclave for PCE fail [load_pce], SGXError:200e.
[2024-05-22T12:54:10.033Z WARN  integritee_service::main_impl] Setting up DCAP - qe_get_quote_size failed with error: SgxQuote(SGX_QL_INTERFACE_UNAVAILABLE), continuing.
Worker Config: Config { integritee_rpc_url: "ws://127.0.0.1", integritee_rpc_port: "9944", target_a_parentchain_rpc_url: None, target_a_parentchain_rpc_port: None, target_b_parentchain_rpc_url: None, target_b_parentchain_rpc_port: None, worker_ip: "0.0.0.0", trusted_external_worker_address: None, trusted_worker_port: "2000", untrusted_external_worker_address: None, untrusted_worker_port: "2001", mu_ra_external_address: None, mu_ra_port: "3490", enable_metrics_server: false, metrics_server_port: "8787", untrusted_http_port: "4545", data_dir: "/tmp/data-dir", run_config: Some(RunConfig { skip_ra: true, dev: true, shard: None, teeracle_update_interval: None, reregister_teeracle_interval: None, marblerun_base_url: None, shielding_target: None }) }
Integritee Worker for sidechain v0.13.0
  DCAP is disabled
  Production Mode is disabled
  EVM is disabled
MRENCLAVE=14mHwrZjP83aJL7ZVV1EVYuCwkD8BrNRcK8xWEP8wuK5
MRENCLAVE in hex "00f6d2e0bcb678e55add2f1786b53c3df20f39bbb2505fbc948ead31b5efd9c8"
MU-RA server listening on 0.0.0.0:3490
Enclave account 5FKcV95UUDznT5BRVRmvL5ryBR62y32gvWcxU6U6A5XwLf4r 
[+] Trusted RPC direct invocation server listening on 0.0.0.0:2000
[+] Untrusted RPC server is spawned on: 0.0.0.0:2001 listening to peer sidechain block broadcasts
[2024-05-22T12:54:10.041045Z INFO  enclave_runtime::initialization::parentchain] [Integritee] initializing solochain parentchain components for shard: 0x00f6d2e0bcb678e55add2f1786b53c3df20f39bbb2505fbc948ead31b5efd9c8
[2024-05-22T12:54:10.041066Z ERROR enclave_runtime::error] Returning error StfStateHandler(InvalidShard(0x00f6d2e0bcb678e55add2f1786b53c3df20f39bbb2505fbc948ead31b5efd9c8)) as sgx unexpected.
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: EnclaveApi(Sgx(SGX_ERROR_UNEXPECTED))', service/src/main_impl.rs:843:80
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

My understanding is that init-shard command is DEPRECATED and this line should init new shard for primary worker but it never reaches that point.

Local changes:

So I've removed --clean-reset flag:

kziemianek@kziemianek:~/projects/integritee/worker$ git diff local-setup/config/one-worker.json
diff --git a/local-setup/config/one-worker.json b/local-setup/config/one-worker.json
index dae71259..49290102 100644
--- a/local-setup/config/one-worker.json
+++ b/local-setup/config/one-worker.json
@@ -22,7 +22,6 @@
     {
       "source": "bin",
       "flags": [
-        "--clean-reset",
         "-P",
         "2000",
         "-p",

Launch command: ./local-setup/launch.py local-setup/config/one-worker.json

If I go to tmp/w1/ and run ./integritee-service -d /tmp/data-dir/ init-shard then worker starts properly.

[brenzi]

we always initialize shards explicitly upon first run. But I agree that we need more clarity in implementation and docs about this. Indeed, auto-initialize was the aim at the line you point to. I'll need to look into this.
the easy workaround is the -c flag at first start