Conversation
…s getResource will always return the full file. Bytes[i] brought back the full file as well. Tests and the browser would need to be updated to accept this change.
|
Oh I also changed optionalPositionParameter to optionParameter on these lines: .addPositionalParam("filePath", "Relative path of the file to upload (from build folder)", "", types.string) Because when I tried a command like this .addOptionalParam("filePath", "Relative path of the file to upload (from build folder)", "", types.string) And then I could do If you can get the optional position parameters to work with 2 parameters and a network flag it's all good with me. |
|
Oh I also added hardhat verify and typechain. I think typechain should be in dev dependencies since it's needed. |
What I discovered when testing the chunking system was that any time you query bytes[] with any index, i.e. bytes[0], bytes[1] etc.. the entire bytes array was returned. The tests and javascript writing function would then slice just the part of the returned array to check if the chunk matched, but the entire array was always returned.
I also discovered that chunks past the first index would always fail because solidity does not appear to let you write to any specific index in a variable bytes array so very long files would fail. You can test this by using the long index file in this pull request on the current web-contract main branch. The error you may encounter will be
ProviderError: execution reverted: out-of-bounds access of an array or bytesNbut it's currently hidden unless you show the error on line 167 of writeToContract.ts in the main branch. So you must console log this error or it will just say "File not found with index /" when you try to write a very long file.Anyway all of this is just my suggestion and it simplifies to getResource and setResource while still keeping the chunking which I think is elegant. The next step would be to add a fallback() function that points to getResource(/) to be more compatible with 4804 just in case. Feedback welcome.