Hi @CodeSandwich thanks for your suggestion

I think this can be resolved by implementing the cheatcodes outlined in #4732

Marking in favor of that ticket, let me know if this is not accurate

Hi @zerosnacks,
Thank you for the insight, but I disagree with your assessment. #4732 is about addresses of deployed contracts, and this issue is about the transactions that are being made. These are 2 very different functionalities, and getting deployed contract addresses does NOT enable access to transaction hashes.

I see, would it be solved if there was a cheatcode that would return additional information (struct Broadcast {...}, like a getBroadcast(string calldata artifactPath) returns (Broadcast broadcast) which includes both transactions and receipts?

A broadcast log looks like:

{
  "transactions": [
    {
      "hash": "0x26b118bd763de327628f1bf80044f6f9fe3d4156fdd398e642eb5d3f598f1903",
      "transactionType": "CREATE",
      "contractName": "Counter",
      "contractAddress": "0x5FbDB2315678afecb367f032d93F642f64180aa3",
      "function": null,
      "arguments": null,
      "transaction": {
        "from": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
        "gas": "0x21de9",
        "value": "0x0",
        "input": "0x6080604052348015600f57600080fd5b5060f78061001e6000396000f3fe6080604052348015600f57600080fd5b5060043610603c5760003560e01c80633fb5c1cb1460415780638381f58a146053578063d09de08a14606d575b600080fd5b6051604c3660046083565b600055565b005b605b60005481565b60405190815260200160405180910390f35b6051600080549080607c83609b565b9190505550565b600060208284031215609457600080fd5b5035919050565b60006001820160ba57634e487b7160e01b600052601160045260246000fd5b506001019056fea26469706673582212206f50ba8504b6682acd965d700b0254b0037881473e4cbfeec4e384a3a84b25ad64736f6c634300081b0033",
        "nonce": "0x0",
        "chainId": "0x7a69"
      },
      "additionalContracts": [],
      "isFixedGasLimit": false
    }
  ],
  "receipts": [
    {
      "status": "0x1",
      "cumulativeGasUsed": "0x1a0ed",
      "logs": [],
      "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
      "type": "0x2",
      "transactionHash": "0x26b118bd763de327628f1bf80044f6f9fe3d4156fdd398e642eb5d3f598f1903",
      "transactionIndex": "0x0",
      "blockHash": "0x1bc0d6b4ed134a975e24c3d7ef64be4955aedd3dd728c01a956bc9c25c3d8ce0",
      "blockNumber": "0x1",
      "gasUsed": "0x1a0ed",
      "effectiveGasPrice": "0x3b9aca01",
      "blobGasPrice": "0x1",
      "from": "0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266",
      "to": null,
      "contractAddress": "0x5FbDB2315678afecb367f032d93F642f64180aa3",
      "root": "0x77a991671f45707778fafeb999ad80ec0c801d2cfb1b5683aa34a7ba0a39ba9b"
    }
  ],
  "libraries": [],
  "pending": [],
  "returns": {},
  "timestamp": 1728567099,
  "chain": 31337,
  "commit": "faef157"
}

From which we could extract the transaction hashes, etc..

If so, I still think we can expand the scope of #4732 to include this request

Yes, getBroadcast effectively returning the content of the broadcast summary JSON would be a great solution, it would cover the need for transaction hashes.

Is there a need for the artifactPath parameter? Scripts can't discover the previous runs, so it would require somebody to manually find the right broadcast/<SCRIPT>/<CHAIN-ID>/run-<ID>.json path and somehow passed it into the script. How would it be useful anyway? IMO artifactPath could be dropped and getBroadcast() could always return the current run information. I'm not even sure if run-latest.json is even available until the script ends running.

I don't think that it would be a viable alternative to #4732 though, these reports have limited usability when it comes to getting the deployed contracts. They only work if the script deploys a contract directly, as in vm.broadcast(); new MyContract();. Any indirection, like using CREATE3, calling a factory or deploying a contract that itself deploys another contract, makes the broadcast report omit the deployed contracts. The VM knows about all created contracts, so it can obtain all the information and serve it in a specialized cheatcode.

Re-opening as it is significantly different from #4732 and possibly requires a different approach.

You make a good point regarding indirection.

This requires some further exploration in regards to how much context a cheatcode can have in regards to transaction hashes as, to my knowledge, the transactions are collected in order and then executed at the end of the run.

Also related: #3589, can imagine another version that does not wait for the receipt

Good catch, I think that this issue may be a duplicate of #3589. I'm not sure if forge script can access the TX hashes without explicitly waiting for them, so vm.waitForTransaction could be the the only viable design here.