Unstable state after 2 exploit code calls almost simultaneously

[claudioantonio]

Steps to reproduce:

1. Create a new bounty for solidity (/bounties/examples/solidity-0.8.26-bounty_riscv64.tar.xz).
2. Open the details of this new bounty and click on "Submit exploit" button.
3. Duplicate the window to have the same bounty on 2 windows and make them visible side by side.
4. Click "Test exploit" for the following code on the window on the left.

   contract test {}

5. It is expected the following output:

   
   Warning: SPDX license identifier not provided in source file. Before publishing, consider adding a comment containing "SPDX-License-Identifier: <SPDX-License>" to each source file. Use "SPDX-License-Identifier: UNLICENSED" for non-open-source code. Please see https://spdx.org for more information.
   --> /exploit

Warning: Source file does not specify required compiler version! Consider adding "pragma solidity ^0.8.26;" --> /exploit

application exited with status 0, exploit failed! [bwrapbox] application exited with status 1 after 172032 real usecs and CPU 148416 usecs

6. "Test exploit"with  the same solidity code on the window in the right and it is expected to produce the same output as indicated on step 5.
7. Now that you have the same solidity code on both windows, click "Test exploit" on the window on the left and, while it is still running, click "Test exploit" on the window on the right.
8. You are expected to receive the output as presented in step 5 on the window on the left, but on the window on the right you will receive the following error.

Unexpected token 'F', "Failed to "... is not valid JSON

9. Now you can "Test exploit" again on the window on the left and the output will the same presented on step 8.
10. At this point the dapp's node seems to become unstable. For example, if you create a new bounty after it, the corresponding input will be sent to the blockchain (you can check it on CartesiScan), but the new bounty will not be presented on the frontend.

### Expected behavior:
I understood that the node had a queue for inspects, so the second call would be handled only after the first call had been finished.

[guidanoli]

Unexpected token 'F', "Failed to "... is not valid JSON

Maybe this error was raised here?

https://github.com/crypto-bug-hunters/bug-buster/blob/89ab74c05d5da0b5c78c85d5e8a0ffc51c836deb/frontend/src/app/bounty/%5BbountyId%5D/exploit/page.tsx#L101

[claudioantonio]

When error described here occurs, the inspect server goes down. We can see it in the browser's console:

POST https://optimism-sepolia.sunodo.app/0x3694c82fde031b8462e90e8bfee0377de2b01ecc/inspect 400 (Bad Request)

This is confirmed by the logs provided by the infra team: "Failed to inspect state: session is tainted"

[rollups-node] 2024-07-18T14:59:22.153 WRN services/command.go:109 WARN HTTP request: tracing_actix_web::middleware: Error encountered while processing the incoming HTTP request: "Failed to inspect state: session is tainted" http.method=POST http.route=/inspect http.flavor=1.1 http.scheme=https http.host=optimism-sepolia-0x3694c82fde031b8462e90e8bfee0377de2b01ecc.fly.dev http.client_ip=201.17.82.12 http.user_agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 http.target=/inspect otel.name=HTTP POST /inspect otel.kind="server" request_id=19c80bed-742b-4116-9f58-e35d68514552 exception.message=Failed to inspect state: session is tainted exception.details="Failed to inspect state: session is tainted" http.status_code=400 otel.status_code="OK" service=inspect-server
[rollups-node] 2024-07-18T14:59:22.152 WRN services/command.go:109 WARN HTTP request: inspect_server::server: Failed to inspect state: session is tainted http.method=POST http.route=/inspect http.flavor=1.1 http.scheme=https http.host=optimism-sepolia-0x3694c82fde031b8462e90e8bfee0377de2b01ecc.fly.dev http.client_ip=201.17.82.12 http.user_agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 http.target=/inspect otel.name=HTTP POST /inspect otel.kind="server" request_id=19c80bed-742b-4116-9f58-e35d68514552 service=inspect-server
[rollups-node] 2024-07-18T14:59:22.152 DBG services/command.go:109 DEBUG inspect_server::inspect: got grpc response from inspect_state response=Err(Status { code: DataLoss, message: "session is tainted", metadata: MetadataMap { headers: {"content-type": "application/grpc"} }, source: None }) request_id=e210d63d-5644-47e4-9752-ab510c0f4738 service=inspect-server
[rollups-node] 2024-07-18T14:59:22.152 DBG services/command.go:109 DEBUG inspect_server::inspect: calling grpc inspect_state request=InspectStateRequest { session_id: "default_session_id", query_payload: [123, 34, 98, 111, 117, 110, 116, 121, 73, 110, 100, 101, 120, 34, 58, 49, 48, 44, 34, 101, 120, 112, 108, 111, 105, 116, 34, 58, 34, 89, 50, 57, 117, 100, 72, 74, 104, 89, 51, 81, 103, 100, 71, 86, 122, 100, 72, 116, 57, 34, 125] } request_id=e210d63d-5644-47e4-9752-ab510c0f4738 service=inspect-server
[rollups-node] 2024-07-18T14:59:22.152 DBG services/command.go:109 DEBUG HTTP request: inspect_server::inspect: inspect request added to the queue http.method=POST http.route=/inspect http.flavor=1.1 http.scheme=https http.host=optimism-sepolia-0x3694c82fde031b8462e90e8bfee0377de2b01ecc.fly.dev http.client_ip=201.17.82.12 http.user_agent=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36 http.target=/inspect otel.name=HTTP POST /inspect otel.kind="server" request_id=19c80bed-742b-4116-9f58-e35d68514552 service=inspect-server

[claudioantonio]

As the problem affects the inspect server, the issue described here is not isolated to the bounty in which it originally occurred.

[guidanoli]

Never mind. If the error was in the line I suggested, it would have never reached the line where it updates the shell text.

[claudioantonio]

The error was happening because:

• we were running the node in a modest cloud VM (1CPU and 1GB ram) on fly.io. We need at least 2 CPU and 1GB ram.
• Besides that we learned that some setup on sunodo's infra had time out settings that once updated to 60s allowed us to execute 5 inspects in parallel.

More info: https://discord.com/channels/600597137524391947/1166042819782258788/1265467379618549802