All committers have signed the CLA.

@0xZRA provided some feedback. Lmk if you have any questions. I'll run the CI when you make those changes and I can investigate if/why the tests are failing.

Hey @0xZRA, will provide some more feedback soon. Sorry for the delay.

Hey @0xZRA okay so I think we need to change our approach. Tbh I didn't expect go generate to complain about this (sorry about that). So, going back to the original problem: we need to (de)serialize the big.Ints. Another way to approach this is to create a custom type (type ContractBalance *big.Int). Thus, the TargetContractBalances will become of type []ContractBalance. Now, we can write our own custom MarshalJSON and UnmarshalJSON that will marshal the ContractBalance to a string and unmarshal from a string to a *big.Int. Here is a stack overflow post that should get you in the right direction: https://stackoverflow.com/questions/53991835/how-to-marshal-and-unmarshal-big-int-in-json

Doing it this way will remove any requirement for go generate so you can remove the directive and the associated file as well.

I would like to take it one more step than what is mentioned in the stack overflow post. I would like to be able to unmarshal any three of these string possibilities:

1. Base-10 string: "1234" or "45678"
2. Hex string: "0xabcdef"
3. Scientific notation for base-10 strings (optional if it is easy): "1.2e18"

Let me know if you have any questions.

Also, about the failing tests: We have some challenging unit tests that sometimes takes medusa a while to solve. That's why sometimes the tests may fail to run. Usually, re-running it does the trick but I do need to investigate why it is happening more frequently nowadays.

Hey @0xZRA okay so I think we need to change our approach. Tbh I didn't expect go generate to complain about this (sorry about that). So, going back to the original problem: we need to (de)serialize the big.Ints. Another way to approach this is to create a custom type (type ContractBalance *big.Int). Thus, the TargetContractBalances will become of type []ContractBalance. Now, we can write our own custom MarshalJSON and UnmarshalJSON that will marshal the ContractBalance to a string and unmarshal from a string to a *big.Int. Here is a stack overflow post that should get you in the right direction: https://stackoverflow.com/questions/53991835/how-to-marshal-and-unmarshal-big-int-in-json

Doing it this way will remove any requirement for go generate so you can remove the directive and the associated file as well.

I would like to take it one more step than what is mentioned in the stack overflow post. I would like to be able to unmarshal any three of these string possibilities:

1. Base-10 string: "1234" or "45678"
2. Hex string: "0xabcdef"
3. Scientific notation for base-10 strings (optional if it is easy): "1.2e18"

Let me know if you have any questions.

Also, about the failing tests: We have some challenging unit tests that sometimes takes medusa a while to solve. That's why sometimes the tests may fail to run. Usually, re-running it does the trick but I do need to investigate why it is happening more frequently nowadays.

@anishnaik I appreciate your response and I think it makes sense so far. Just wanted to clarify one point in your approach regarding the unmarshalling of the 3 string possibilities. Does the proposed approach still involve maintaining the current hexadecimal notation for setting initial balances, while adding the option to use base-10 strings, including scientific notation?

So if we take it straight to the docs, the new version will look like:

targetContractsBalances

• Type: [Base-16 Strings] (e.g. [0x123, 0x456, 0x789])
• Type: [Base-10 Strings] (e.g. ["123", "1000000", "115792089237316195423570985008687907853269984665640564039457584007913129639935"])
• Type: [Base-10 Strings Scientific Notation] (e.g. ["1.23e2", "1.0e6", "1.15792089237316195423570985008687907853269984665640564039457584007913129639935e77"])

Technically, you can also mix and match: ["1e12", "0x1234", "5678"]. Since you are evaluating each string individually, and not the whole array, the logic shouldn't change depending on what the array looks like.

Like the UnmarshalJSON function you write will take a []byte and you need to convert it into a ContractBalance (aka *big.Int). This []byte could be any of the three string possibilities (or invalid).

Also, for MarshalJSON, always just serialize it as a base-10 string.

This PR became more complicated than I expected :)

Technically, you can also mix and match: ["1e12", "0x1234", "5678"]. Since you are evaluating each string individually, and not the whole array, the logic shouldn't change depending on what the array looks like.

Like the UnmarshalJSON function you write will take a []byte and you need to convert it into a ContractBalance (aka *big.Int). This []byte could be any of the three string possibilities (or invalid).

Also, for MarshalJSON, always just serialize it as a base-10 string.

This PR became more complicated than I expected :)

I hadn't thought of mix and match, you're right. I'll take a shot at it.

This is still WIP, as I haven't tested the actual runs with different balance formats. @anishnaik let me know if I captured the requirements correctly

@anishnaik I hope I addressed all issues except these 2:
#580 (comment)
#580 (comment)
Let me know whenever you get a chance

Okay one more round of final nitpicks and review :)

No problem, will do

@anishnaik Thank you for your comments, I hope I addressed latest round of feedback.

Hey @0xZRA looks great! Can you run npm prettier . --write in the docs/ folder? It will help the linter pass in the CI. PS you will probably have to download prettier which you can do via npm -g install prettier.

@anishnaik just pushed the change after running prettier

@0xZRA, it seems like docs/theme/highlight.js has been added to this PR which we don't want. Can you remove it from this PR?

Another linter is complaining about this line in MarshalJSON:
return []byte(fmt.Sprintf("%s", cb.Int.String()))

You can change it to
return []byte(cb.Int.String())

and that should be sufficient.

@0xZRA, I think there was a misunderstanding on my part around highlight.js (my mistake). What I meant was to revert the changes that prettier made to that .js file. But honestly it doesn't matter. Can you add the .js file back to this PR?

@0xZRA, I think there was a misunderstanding on my part around highlight.js (my mistake). What I meant was to revert the changes that prettier made to that .js file. But honestly it doesn't matter. Can you add the .js file back to this PR?

I feel like all these things could be caught and understood by me better before pushing to origin ;( Thanks for your patience

@anishnaik I'm able to reproduce the test(s) failure locally but I'm not sure why sequence of 71 and 7 is triggering violated state (I'm not talking about how x becomes 10 and y becomes 80), I'm rather trying to understand under which condition the failure became possible.

1) InheritedFirstContract.setY(uint256)(71) (block=4, time=165981, gas=12500000, gasprice=1, value=0, sender=0x30000)
2) InheritedFirstContract.setX(uint256)(7) (block=24092, time=602323, gas=12500000, gasprice=1, value=0, sender=0x10000)
[Execution Trace]
 => [call] InheritedFirstContract.setX(uint256)(7) (addr=0xA647ff3c36cFab592509E13860ab8c4F28781a66, value=0, sender=0x10000)
         => [return ()]

[Property Test Execution Trace]
[Execution Trace]
 => [call] InheritedFirstContract.property_never_specific_values()() (addr=0xA647ff3c36cFab592509E13860ab8c4F28781a66, value=0, sender=0x10000)
         => [return (false)]

⇾ Test summary: 1 test(s) passed, 1 test(s) failed

Hey @0xZRA, honestly that specific test has been failing more frequently these days, I am unsure why. But luckily doesn't have anything to do with this PR. Going to merge now, thank you so much for the help and great job!

@anishnaik Thanks for your guidance and opportunity to help!