esp-miner is unable to handle difficulty change following with "mining.notify" when `cleanJob` set to false

[blackmennewstyle]

Hello beautiful dev(s),

Why is esp-miner unable to handle properly the following scenario:

• The stratum sends a mining.set_difficulty following with mining.notify with thecleanJob indicator set to false.

esp-miner then starts to send duplicate shares, the same solution with the same nonce, over and over again until the stratum sends another mining.notify with the cleanJob indicator set to true.

The behavior is clearly visible in my attachment file.

It is way more easy to reproduce that behavior on BTC testnet4 by the way.

2026-03-02 16:52:49.4134] [I] [btc1] [0HNJOFCT4H9CS] VarDiff update to 9427.961
[2026-03-02 16:52:49.4134] [D] [btc1] [0HNJOFCT4H9CS] Sending: {"jsonrpc":"2.0","method":"mining.set_difficulty","params":[9427.960695338843],"id":null} 
[2026-03-02 16:52:49.4134] [D] [btc1] [0HNJOFCT4H9CS] Sending: {"jsonrpc":"2.0","method":"mining.notify","params":["00000006","61579a01acc1daa4da7e43b1a67de71112b9133d44fc8e2d0784e99700000000","01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff32033ee60104febfa56900","1f4d696e696e67636f72652f436564726963204352495350494e2f61735f544800000000020000000000000000266a24aa21a9ede4c58cf54dd9bf607f7c904968305679ab9226e3e338418e24a7245d3e8554a89a33312a010000001976a914b39a791bdaa16ec039fbabe4e46efb7cab150c5388ac00000000",["2aeff42e83cf2fa7a271c9e600923458e5b44d3cc086b68fd5e1bd2f8fb2c2f4","8d88f91b9c3d3748e2e5c3b324db6825c4e9fd5051c5617de6a271da2b4b8b87","7ab6d88c0da99231f817a1a588ccf941ded398e24ec1510745dd23459444770c","bd52c7bdc423945a8a9bafaa0738c7a0edd32792506743acd39c9593cf964d43","c076078e0fc41fbc4ef1e8ed3368516bde09b8d98cf13246a1f63bd25c902099","0467ec38d4df01dc161f2aec3ef865832d8d1689067bb155d5aa359b0433de55"],"20000000","190336be","69a5c579",false],"id":null}
[2026-03-02 16:53:19.4715] [D] [btc1] [0HNJOFCT4H9CS] [NET] Received data: {"id":21,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.janus","00000006","3b000000","69a5c579","ad910248","02cc2000"]}
[2026-03-02 16:53:19.4715] [D] [btc1] [0HNJOFCT4H9CS] [PIPE] Received data: {"id":21,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.janus","00000006","3b000000","69a5c579","ad910248","02cc2000"]}
[2026-03-02 16:53:19.4715] [D] [btc1] [0HNJOFCT4H9CS] Dispatching request 'mining.submit' [21] 
[2026-03-02 16:53:19.4715] [I] [btc1] [0HNJOFCT4H9CS] Share rejected: duplicate share [bitaxe/BM1370/v2.13.0] 
[2026-03-02 16:53:19.4725] [D] [btc1] [0HNJOFCT4H9CS] Sending: {"result":false,"error":{"code":22,"message":"duplicate share","data":null},"id":21} 
[2026-03-02 16:53:58.8370] [D] [btc1] [0HNJOFCT4H9CS] [NET] Received data: {"id":22,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.janus","00000006","89000000","69a5c579","debe0186","0555e000"]}
[2026-03-02 16:53:58.8370] [D] [btc1] [0HNJOFCT4H9CS] [PIPE] Received data: {"id":22,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.janus","00000006","89000000","69a5c579","debe0186","0555e000"]}
[2026-03-02 16:53:58.8370] [D] [btc1] [0HNJOFCT4H9CS] Dispatching request 'mining.submit' [22] 
[2026-03-02 16:53:58.8370] [I] [btc1] [0HNJOFCT4H9CS] Share rejected: duplicate share [bitaxe/BM1370/v2.13.0] 
[2026-03-02 16:53:58.8370] [D] [btc1] [0HNJOFCT4H9CS] Sending: {"result":false,"error":{"code":22,"message":"duplicate share","data":null},"id":22} 
[2026-03-02 16:54:04.4307] [D] [btc1] [0HNJOFCT4H9CS] [NET] Received data: {"id":23,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.janus","00000006","95000000","69a5c579","5d110336","00218000"]}
[2026-03-02 16:54:04.4307] [D] [btc1] [0HNJOFCT4H9CS] [PIPE] Received data: {"id":23,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.janus","00000006","95000000","69a5c579","5d110336","00218000"]}
[2026-03-02 16:54:04.4307] [D] [btc1] [0HNJOFCT4H9CS] Dispatching request 'mining.submit' [23] 
[2026-03-02 16:54:04.4307] [I] [btc1] [0HNJOFCT4H9CS] Share rejected: duplicate share [bitaxe/BM1370/v2.13.0]
[2026-03-02 16:54:04.4307] [D] [btc1] [0HNJOFCT4H9CS] Sending: {"result":false,"error":{"code":22,"message":"duplicate share","data":null},"id":23}
[2026-03-02 16:54:28.8262] [D] [btc1] [0HNJOFCT4H9CS] [PIPE] Received data: {"id":24,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.janus","00000006","c5000000","69a5c579","0f870304","03c8e000"]}
[2026-03-02 16:54:28.8262] [D] [btc1] [0HNJOFCT4H9CS] Dispatching request 'mining.submit' [24] 
[2026-03-02 16:54:28.8262] [I] [btc1] [0HNJOFCT4H9CS] Share rejected: duplicate share [bitaxe/BM1370/v2.13.0] 
[2026-03-02 16:54:28.8262] [D] [btc1] [0HNJOFCT4H9CS] Sending: {"result":false,"error":{"code":22,"message":"duplicate share","data":null},"id":24} 
[2026-03-02 16:54:37.1131] [I] [btc1] Detected new transaction(s) for block 124479 [ZMQ] 
[2026-03-02 16:54:37.1131] [I] [btc1] Broadcasting job 00000007 
[2026-03-02 16:54:37.1131] [D] [btc1] [0HNJOFCT4H9CS] Sending: {"jsonrpc":"2.0","method":"mining.notify","params":["00000007","e1341f7cd8871844a42e8081a93a9ca2ee4207f8278e6e850b69744100000000","01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff32033fe60104cdc0a56900","1f4d696e696e67636f72652f436564726963204352495350494e2f61735f544800000000020000000000000000266a24aa21a9ed826036f770667aea70eb70f91f50d1ac60245c20725d93dbec42a41711e4ba6762023a2a010000001976a914b39a791bdaa16ec039fbabe4e46efb7cab150c5388ac00000000",["2aeff42e83cf2fa7a271c9e600923458e5b44d3cc086b68fd5e1bd2f8fb2c2f4","5913bd4a1332e085c975e851375027ce57c2b66a865eb11085ab1b26fa59ea55","7ab6d88c0da99231f817a1a588ccf941ded398e24ec1510745dd23459444770c","bd52c7bdc423945a8a9bafaa0738c7a0edd32792506743acd39c9593cf964d43","c076078e0fc41fbc4ef1e8ed3368516bde09b8d98cf13246a1f63bd25c902099","0467ec38d4df01dc161f2aec3ef865832d8d1689067bb155d5aa359b0433de55"],"20000000","190336be","69a5ca29",true],"id":null} 

[skot]

looking at your log files, it doesn't seem like these are actually duplicate shares. Are you getting the mining.submit JobID and nonce fields mixed up?

[mutatrum]

This might be related: #420 (comment). My suspicion is that the mining.notify doesn't trigger the queue_dequeue_timeout in the create_jobs_task, but I haven't figured it out completely yet.

[blackmennewstyle]

looking at your log files, it doesn't seem like these are actually duplicate shares. Are you getting the mining.submit JobID and nonce fields mixed up?

Thanks for your answer.
But it is definitely not mixed up inside miningcore (stratum software), jobId is not involved during the job hashing process only prior in order to find the correct job class/object.

Here the code which checks for duplicate shares, it is tied to each job class/object, stored inside a dictionnary:

    protected bool RegisterSubmit(string extraNonce1, string extraNonce2, string nTime, string nonce)
    {
        var key = new StringBuilder()
            .Append(extraNonce1)
            .Append(extraNonce2)
            .Append(nTime)
            .Append(nonce)
            .ToString();

        return submissions.TryAdd(key, true);
    }

You can analyze the mining.submit:

{"id":21,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.janus","00000006","3b000000","69a5c579","ad910248","02cc2000"]}

index 0: worker
index 1: jobId
index 2: extranonce2
index 3: nTime
index 4: nonce
(optional index 5: versionBits)

extranonce1 is only known by the stratum and each worker has an unique one until a specific number based on the extranonce1 size, here 4 bits.

It's a very odd issue i agree but the fact it is always triggered by a mining.set_difficulty following by a mining.notify with a cleanJob set to false, points definitely toward a little glitch in the mining software.

@mutatrum I think you might be on something.

[skot]

looking at your log files, it doesn't seem like these are actually duplicate shares. Are you getting the mining.submit JobID and nonce fields mixed up?

Thanks for your answer.
But it is definitely not mixed up inside miningcore (stratum software), jobId is not involved during the job hashing process only prior in order to find the correct job class/object.

Here the code which checks for duplicate shares, it is tied to each job class/object, stored inside a dictionnary:

    protected bool RegisterSubmit(string extraNonce1, string extraNonce2, string nTime, string nonce)
    {
        var key = new StringBuilder()
            .Append(extraNonce1)
            .Append(extraNonce2)
            .Append(nTime)
            .Append(nonce)
            .ToString();

        return submissions.TryAdd(key, true);
    }

You can analyze the mining.submit:

{"id":21,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.janus","00000006","3b000000","69a5c579","ad910248","02cc2000"]}

index 0: worker
index 1: jobId
index 2: extranonce2
index 3: nTime
index 4: nonce
(optional index 5: versionBits)

extranonce1 is only known by the stratum and each worker has an unique one until a specific number based on the extranonce1 size, here 4 bits.

It's a very odd issue i agree but the fact it is always triggered by a mining.set_difficulty following by a mining.notify with a cleanJob set to false, points definitely toward a little glitch in the mining software.

@mutatrum I think you might be on something.

Look at your log. These aren't duplicate shares.

[mutatrum]

I didn't read the logs complete, but that's right. Each mining.submit has a different extranonce2, nonce and versionBits field:

{"id":21,"method":"mining.submit","params":["...","00000006","3b000000","69a5c579","ad910248","02cc2000"]}
{"id":22,"method":"mining.submit","params":["...","00000006","89000000","69a5c579","debe0186","0555e000"]}
{"id":23,"method":"mining.submit","params":["...","00000006","95000000","69a5c579","5d110336","00218000"]}
{"id":24,"method":"mining.submit","params":["...","00000006","c5000000","69a5c579","0f870304","03c8e000"]}

[blackmennewstyle]

I don't quite understand your counter-argument here.

The way it works guys, if these combos of extranonce1, extranonce2, nonce & nTime have already been registered previously in the dictionnary, they will will be rejected if they are submitted again.

// extract params
var workerValue = (submitParams[0] as string)?.Trim();
var jobId = submitParams[1] as string;
var extraNonce2 = submitParams[2] as string;
var nTime = submitParams[3] as string;
var nonce = submitParams[4] as string;
var versionBits = context.VersionRollingMask.HasValue ? submitParams[5] as string : null;

Let's refer to documentation: https://learn.microsoft.com/en-us/dotnet/api/system.collections.generic.dictionary-2.tryadd?view=net-6.0

Remarks

Unlike the Add method, this method doesn't throw an exception if the element with the given key exists in the dictionary. Unlike the Dictionary indexer, TryAdd doesn't override the element if the element with the given key exists in the dictionary. If the key already exists, TryAdd does nothing and returns false.

In simple terms again, those combos were all submitted already. You have unfortunately a glitch in your code.

[DankMiner]

This looks like a client-side nonce tracking issue.

When mining.set_difficulty is followed by mining.notify with cleanJob=false, ESP-Miner doesn't reset its nonce state or re-feed the ASIC with the updated job. So the ASIC keeps scanning the same nonce space and resubmits solutions the pool already saw, hence the duplicate rejections.

The fix should be: on any mining.notify (regardless of cleanJob), reset the submitted-nonce tracking and update the ASIC work params with the new job ID. The cleanJob=false flag means "don't abandon valid in-progress work," not "ignore this job entirely."

The reset logic clearly exists already since cleanJob=true works fine, it just needs to also trigger the nonce/job-ID refresh on the false path.

[mutatrum]

Is this with m45core, or which stratum implementation? As I'm a bit confused with the context now. F.e. ckpool has vardiff, and I haven't seen duplicate shares there.

Can you share the logs from the miner side, where you see it send a share, receive the diff adjustment, and resend the same share? It's really difficult to reason with logs from the other side.

Which firmware is running on the miner, and what device is it?

[blackmennewstyle]

Is this with m45core, or which stratum implementation? As I'm a bit confused with the context now. F.e. ckpool has vardiff, and I haven't seen duplicate shares there.

Can you share the logs from the miner side, where you see it send a share, receive the diff adjustment, and resend the same share? It's really difficult to reason with logs from the other side.

Which firmware is running on the miner, and what device is it?

Stratum software is miningcore written in C#, devices are BitAxe 601 (Gamma?), on latest firmware.

I put one of my BitAxe on CKPool all afternoon and i am getting rejected shares, they are of type unknown, sadly the log feature is quite limited so i can not see the rejected shares. If there is a way please feel free to share.

One thing i noticed however, the varDiff on CKPool is very very slow, which generally means, it is configured to mitigate as much as possible most issues.

[mutatrum]

When mining.set_difficulty is followed by mining.notify with cleanJob=false, ESP-Miner doesn't reset its nonce state or re-feed the ASIC with the updated job. So the ASIC keeps scanning the same nonce space and resubmits solutions the pool already saw, hence the duplicate rejections.

This is by design. There is a 500ms timeout on single chip devices, and if cleanJob=false, the job will only be cycled after this timeout. On a Gamma, the nonce space currently takes about 2.8 seconds IIRC, so it should not cause duplicates.

I think there's something else going on here, but I don't know what, yet. The unknown rejects from ckpool is fixed by #1586, and is most likely Stale, and not Duplicate, but we can only know this for sure if you would test it with that PR in the firmware.

One way would be to connect the miner to USB, and capture the serial logging directly to a file. That, or capture the log websocket and store it to a file. Either way should give you infinite log retention.

[blackmennewstyle]

When mining.set_difficulty is followed by mining.notify with cleanJob=false, ESP-Miner doesn't reset its nonce state or re-feed the ASIC with the updated job. So the ASIC keeps scanning the same nonce space and resubmits solutions the pool already saw, hence the duplicate rejections.

This is by design. There is a 500ms timeout on single chip devices, and if cleanJob=false, the job will only be cycled after this timeout. On a Gamma, the nonce space currently takes about 2.8 seconds IIRC, so it should not cause duplicates.

I think there's something else going on here, but I don't know what, yet. The unknown rejects from ckpool is fixed by #1586, and is most likely Stale, and not Duplicate, but we can only know this for sure if you would test it with that PR in the firmware.

One way would be to connect the miner to USB, and capture the serial logging directly to a file. That, or capture the log websocket and store it to a file. Either way should give you infinite log retention.

Well,

I tried to build the firmware here and i can not pass that step:

[1574/1627] Linking CXX static library...ssif__esp_lvgl_port/liblvgl_port_lib.a
FAILED: openapi_generate.stamp /workspace/build/openapi_generate.stamp 
cd /workspace/main/http_server/axe-os && /usr/bin/npm i && /usr/bin/npm run generate:api && /opt/esp/tools/cmake/3.30.2/bin/cmake -E touch /workspace/build/openapi_generate.stamp
ninja: build stopped: subcommand failed.
ninja failed with exit code 1, output of the command is in the /workspace/build/log/idf_py_stderr_output_506 and /workspace/build/log/idf_py_stdout_output_506

[blackmennewstyle]

The code change pushed by @DankMiner seems to have made a little difference.

After the difficulty change, the miner only sends a single duplicate share:

[2026-03-09 22:15:47.6068] [I] [btc1] Detected new transaction(s) for block 125426 [POLL] 
[2026-03-09 22:15:47.6068] [I] [btc1] Broadcasting job 00000004 
[2026-03-09 22:15:47.6068] [D] [btc1] [0HNJU531GL5HV] Sending: {"jsonrpc":"2.0","method":"mining.notify","params":["00000004","380766bd7f5c07aa228793f52dd3a3bcedc956337b246a3c0005244300000000","01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff3203f2e901049346af6900","1f4d696e696e67636f72652f436564726963204352495350494e2f61735f544800000000020000000000000000266a24aa21a9ed023607654daef82ab7ebd25935d165d02a0b25cca316d34015c1f9301907fc2f1255172a010000001976a914b39a791bdaa16ec039fbabe4e46efb7cab150c5388ac00000000",["62b7d095e97b004ea73e6d15a501b1a167d8e895820450d0be260e419ed0396c","4cdb5855d4b20acc8337b7fd597b62fc1a68fccf74d1ce1b2611bcdab912bb04","d794b42447af4662cfb6a8027796d23e6a7f454faf5f0ee5d96c82ffa39eca61","359a414ef868b93d00b569f5051d0adfb69febf4a9aa9b3065fb2e72d9e0e85f"],"20000000","190327c4","69af4879",true],"id":null} 
[2026-03-09 22:15:52.5619] [D] [btc1] Vardiff Idle Update pass begins 
[2026-03-09 22:15:52.5619] [D] [btc1] [0HNJU531GL5HV] Updating VarDiff [IDLE] 
[2026-03-09 22:15:52.5619] [D] [btc1] Vardiff Idle Update pass ends 
[2026-03-09 22:16:34.6608] [D] [btc1] [0HNJU531GL5HV] [NET] Received data: {"id":10,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.portia","00000004","5d000000","69af4879","67ea0196","034b4000"]}
 
[2026-03-09 22:16:34.6608] [D] [btc1] [0HNJU531GL5HV] [NET] Waiting for data ... 
[2026-03-09 22:16:34.6608] [D] [btc1] [0HNJU531GL5HV] [PIPE] Received data: {"id":10,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.portia","00000004","5d000000","69af4879","67ea0196","034b4000"]}
 
[2026-03-09 22:16:34.6608] [D] [btc1] [0HNJU531GL5HV] Dispatching request 'mining.submit' [10] 
[2026-03-09 22:16:34.6608] [I] [btc1] [0HNJU531GL5HV] Share accepted: D=8192 
[2026-03-09 22:16:34.6608] [D] [btc1] [0HNJU531GL5HV] Updating VarDiff 
[2026-03-09 22:16:34.6608] [D] [btc1] [0HNJU531GL5HV] Sending: {"jsonrpc":"2.0","result":true,"id":10,"error":null} 
[2026-03-09 22:16:34.6608] [I] [btc1] [0HNJU531GL5HV] VarDiff update to 4585.288 
[2026-03-09 22:16:34.6608] [D] [btc1] [0HNJU531GL5HV] [PIPE] Waiting for data ... 
[2026-03-09 22:16:34.6608] [D] [btc1] [0HNJU531GL5HV] Sending: {"jsonrpc":"2.0","method":"mining.set_difficulty","params":[4585.288492389524],"id":null} 
[2026-03-09 22:16:34.6608] [D] [btc1] [0HNJU531GL5HV] Sending: {"jsonrpc":"2.0","method":"mining.notify","params":["00000004","380766bd7f5c07aa228793f52dd3a3bcedc956337b246a3c0005244300000000","01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff3203f2e901049346af6900","1f4d696e696e67636f72652f436564726963204352495350494e2f61735f544800000000020000000000000000266a24aa21a9ed023607654daef82ab7ebd25935d165d02a0b25cca316d34015c1f9301907fc2f1255172a010000001976a914b39a791bdaa16ec039fbabe4e46efb7cab150c5388ac00000000",["62b7d095e97b004ea73e6d15a501b1a167d8e895820450d0be260e419ed0396c","4cdb5855d4b20acc8337b7fd597b62fc1a68fccf74d1ce1b2611bcdab912bb04","d794b42447af4662cfb6a8027796d23e6a7f454faf5f0ee5d96c82ffa39eca61","359a414ef868b93d00b569f5051d0adfb69febf4a9aa9b3065fb2e72d9e0e85f"],"20000000","190327c4","69af4879",false],"id":null} 
[2026-03-09 22:17:21.6807] [D] [btc1] [0HNJU531GL5HV] [NET] Received data: {"id":11,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.portia","00000004","5d000000","69af4879","67ea0196","034b4000"]}
 
[2026-03-09 22:17:21.6807] [D] [btc1] [0HNJU531GL5HV] [NET] Waiting for data ... 
[2026-03-09 22:17:21.6807] [D] [btc1] [0HNJU531GL5HV] [PIPE] Received data: {"id":11,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.portia","00000004","5d000000","69af4879","67ea0196","034b4000"]}
 
[2026-03-09 22:17:21.6807] [D] [btc1] [0HNJU531GL5HV] Dispatching request 'mining.submit' [11] 
[2026-03-09 22:17:21.6807] [I] [btc1] [0HNJU531GL5HV] Share rejected: duplicate share [bitaxe/BM1370/v2.13.2-1-g5d268fb-dirty] 
[2026-03-09 22:17:21.6807] [D] [btc1] [0HNJU531GL5HV] [PIPE] Waiting for data ... 
[2026-03-09 22:17:21.6856] [D] [btc1] [0HNJU531GL5HV] Sending: {"jsonrpc":"2.0","method":"mining.submit","result":false,"error":{"code":22,"message":"duplicate share","data":null},"id":11} 
[2026-03-09 22:17:51.1859] [D] [btc1] [0HNJU531GL5HV] [NET] Received data: {"id":12,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.portia","00000004","98000000","69af4879","b81303b4","02944000"]}
 
[2026-03-09 22:17:51.1859] [D] [btc1] [0HNJU531GL5HV] [NET] Waiting for data ... 
[2026-03-09 22:17:51.1859] [D] [btc1] [0HNJU531GL5HV] [PIPE] Received data: {"id":12,"method":"mining.submit","params":["tb1qtl9daftpqser8lt7uqdrg82ztn7kxw2t4rsgaj.portia","00000004","98000000","69af4879","b81303b4","02944000"]}
 
[2026-03-09 22:17:51.1859] [D] [btc1] [0HNJU531GL5HV] Dispatching request 'mining.submit' [12] 
[2026-03-09 22:17:51.1859] [I] [btc1] [0HNJU531GL5HV] Share accepted: D=4585.288 
[2026-03-09 22:17:51.1859] [D] [btc1] [0HNJU531GL5HV] Updating VarDiff 
[2026-03-09 22:17:51.1859] [D] [btc1] [0HNJU531GL5HV] Sending: {"jsonrpc":"2.0","result":true,"id":12,"error":null}