bug: fix payment check conflict and flag impact for type hash

[ashuralyk]

Description

payment function needs to pin a flag in script.args filed, which can impact the calculation of script hash, however, if this payment flag changed in transfer operation, we cannot just use GroupInput and GroupOutput to identify the related scripts both in Input and Output field, so this change of payment should be described as Burn/Mint in one transaction.

when we use payment flag to check the user's payment is wether enough, since different scripts in Mutant or Proxy cell act independently, and these scripts use the same logic to run a payment check process, so, for example, if a same owner of two Mutant cells with different mutant_id disappeared in CellDep field at the same time, one payment in transaction will be duplicated in use to meet this two Mutant scripts' requirement.

Tasks list

• close Logic conflict in payment related contracts #15
• close incorrect minimal_payment condition judgement in cluster_agent and spore contract #36
• close Potential silent runtime errors caused by unchecked length #40
• close Potential index out of bounds error which will lead to panic. #39

[ashuralyk]

Currently, Mint/Creation operation can't set minimal_payment_args either？

the change of minimal_payment_args can influent the calculation of type id, known as proxy id here, so different proxy id both in Input and Output cannot recognize as transfer operation, it's just burn and mint instead

@Flouse

[ashuralyk]

Mint/Creation operation can set a ClusterProxy's minimal_payment_args after the type_id

what does this mean? payment args is written in script args, which causes the change of type_id and cannot be altered
@Flouse

[Flouse]

what does this mean? payment args is written in script args, which causes the change of type_id and cannot be altered

I have no questions now.
This PR is approved 13 hours ago.

[ashuralyk]

@Flouse @ShookLyngs I committed some changes, please check again, I closed the other two issues that hasn't been closed

[Flouse]

Suggested change

	run: bash prepare.sh -b $GITHUB_HEAD_REF
	run: bash prepare.sh -b $GITHUB_REF

GITHUB_HEAD_REF is the head ref or source branch of the pull request in a workflow run. This property is only set when the event that triggers a workflow run is either pull_request or pull_request_target.

Suggestions

• Add a push event for this workflow, since it only takes 10 minutes.
  Running devnet test for every pushed commit is acceptable.

• use GITHUB_REF instead of GITHUB_HEAD_REF

  GITHUB_REF: The fully-formed ref of the branch or tag that triggered the workflow run. For workflows triggered by push, this is the branch or tag ref that was pushed. For workflows triggered by pull_request, this is the pull request merge branch. For workflows triggered by release, this is the release tag created.
  See https://docs.github.com/en/actions/learn-github-actions/variables

[ashuralyk]

we used $GITHUB_REF but did not get to our expectation, and for now, $GITHUB_HEAD_REF works fine for us, so it can stay as it is now

[Flouse]

What do you mean it did not get to our expectation?
Is there a GitHub action that contains the error?

[Flouse]

bug: fix remained bugs
I closed the other two issues that hasn't been closed

Next time, it would be nice if you create new PR for each issue.
You know, one PR for one issue.
This allows for better tracking, review, and management of changes.

[Flouse]

These changes may conflict with 1e100f6 in your another PR. You will need to resolve the conflicts later which may take more time.

Again, it is better to solve one small issue in one PR.
For now, it LGTM.

[ashuralyk]

yes, next step is to solve conflict, the time is ok