Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement new step asserting that AtomicTransactionComposer's attempt to add a method can fail with a particular error #347

Merged
merged 7 commits into from Jun 17, 2022

Conversation

tzaffi
Copy link
Contributor

@tzaffi tzaffi commented Jun 14, 2022

Implementing the following step:

I add a method call with the signing account, the current application, suggested params, on complete "noop", current transaction signer, current method arguments; any resulting exception has key "{none-or-exception-key}".

Related Issues and PR's

@tzaffi tzaffi changed the title Imlement new step "the most recently added method call has an exception" Implement new step "the most recently added method call has an exception" Jun 14, 2022
@tzaffi tzaffi changed the title Implement new step "the most recently added method call has an exception" Implement new step "the most recently added method call has an exception..." Jun 14, 2022
@@ -7,7 +7,7 @@ pushd $rootdir

# Reset test harness
rm -rf test-harness
git clone --single-branch --branch master https://github.com/algorand/algorand-sdk-testing.git test-harness
git clone --single-branch --branch abi-too-many-args https://github.com/algorand/algorand-sdk-testing.git test-harness
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: revert to point back to master before merging this PR.

@@ -85,16 +89,32 @@ def s512_256_uint64(witness):
return int.from_bytes(encoding.checksum(witness)[:8], "big")


@step(
Copy link
Contributor Author

@tzaffi tzaffi Jun 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved unchanged from other_v2_steps after I realized that this is meant for application transactions

@@ -159,8 +179,13 @@ def lookup_application_include_all2(
context.response = json.loads(str(e))


@when("we make a LookupApplications call with applicationID {app_id}")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved closer to similar function

@when("I use {indexer} to lookup application with {application_id}")
def lookup_application(context, indexer, application_id):
def lookup_application2(context, indexer, application_id):
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

renamed to avoid method name collision

@@ -512,35 +537,37 @@ def add_transaction_to_composer(context):
)


def process_abi_args(context, method, arg_tokens):
def process_abi_args(context, method, arg_tokens, erase_empty_tokens=True):
if erase_empty_tokens:
Copy link
Contributor Author

@tzaffi tzaffi Jun 14, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we no longer assume that the lengths of the method args and actual args are the same, a couple of side effects occurred. One side effect is that when "".split() is called on an empty string, you get a non-empty list. As in all existing cases, empty strings that are split were meant to indicate no values at all, so this change shouldn't break any tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused. Is the cause of this change that the step I append the encoded arguments "<app-args>" to the method arguments array now has to work when <app-args> is the empty string?

Or is there another cause?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously, all tests had exactly the same number of runtime args as defined in the method signature. The step logic iterated through the method signature args and accessed the run-time arg with index corresponding to the signature arg. When there were no method signature args, the loop was actually trivial (see the image below). However, in that trivial case, args was actually the list of length 1 containing an empty string [''] (because of how python split works):

>>> "".split(",")
['']

Now that we are no longer assuming that the number of args are the same, the 0 vs. 1 case no longer was correct so I needed to adjust the logic using this hack.

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So yes, it has to work with empty string (which before was actually ignored in a sense).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that explanation, I think I understand now. Alternatively, would it be an acceptable solution to modify the I append the encoded arguments "<app-args>" to the method arguments array step to check if <app-args> is an empty string and do nothing in that case?

The reason I suggest this is because we can semantically still pass empty string args with something like a,,b, and this would be ignored by the current code, but I think it should complain/error for this input.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, you'd have to set erase_empty_tokens to false... still thinking about your first paragraph

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a proposal. Rename this step to:

'I add a method call with the {account_type} account, the current application, suggested params, on complete "{operation}", current transaction signer, current method arguments ignoring empty ones; any resulting exception has key "{exception_key}".'

the phrase "ignoring empty ones" indicates that we should not be allowing empty arguments for this step. And in fact, this step will eventually call process_abi_args(... erase_empty_tokens=True) while all the other steps will continue as before and therefor have erase_empty_tokens=False

Sounds good?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's better, but it still looks like we're addressing the symptoms of the problem, not the root cause. I'd find it simpler if no filtering of arguments needed to be done after the fact, since this seems error-prone and hard to reason about.

Copy link
Contributor Author

@tzaffi tzaffi Jun 17, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying your original suggestion with I append the encoded arguments. Seems to work. We'll see if all the tests pass.

@@ -1406,27 +1406,6 @@ def algod_v2_client(context):
context.app_acl = algod.AlgodClient(daemon_token, algod_address)


@step(
'I sign and submit the transaction, saving the txid. If there is an error it is "{error_string:MaybeString}".'
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

moved this to application_v2_steps.py

@tzaffi tzaffi changed the title Implement new step "the most recently added method call has an exception..." Implement new step asserting that AtomicTransactionComposer's attempt to add a method can fail with a particular error Jun 16, 2022
run_integration.sh Outdated Show resolved Hide resolved
Copy link
Member

@jasonpaulos jasonpaulos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@tzaffi tzaffi merged commit 989893a into develop Jun 17, 2022
@tzaffi tzaffi deleted the abi-too-many-args-steps branch June 17, 2022 21:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants