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

[ADHOC] feat(sdk,EventAction): add msgSenderClaimant utility, test #221

Merged
merged 3 commits into from
Oct 23, 2024

Conversation

sammccord
Copy link
Contributor

🚨 Please review the guidelines for contributing to this repository.

Description

add msgSenderClaimant utility to event action
add tsdoc
add test
some autoformatting hath occured

💔 Thank you!

Copy link

changeset-bot bot commented Oct 23, 2024

🦋 Changeset detected

Latest commit: 230780e

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages
Name Type
@boostxyz/sdk Minor
@boostxyz/cli Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@sammccord
Copy link
Contributor Author

Warnings
⚠️

By using the [ADHOC] title prefix, you are bypassing best practice protections.

Generated by 🚫 dangerJS against 7d4d352

@@ -516,6 +519,29 @@ export class EventAction extends DeployableTarget<
params: ValidateActionStepParams,
): Promise<Address | undefined> {
const signature = claimant.signature;

// find message sender and return it
// WARNING: this is error prone in bridged transactions, as from will be exit node
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe it should be a dev note in the jsdocs that bridging and internal transactions aren't yet supported

/**
* Creates an ActionClaimant object that represents the msg.sender as the claimant.
* This function is useful when you want to set up an action where the transaction sender
* (msg.sender in Solidity terms) is always considered the valid claimant, regardless of
Copy link
Contributor

@topocount topocount Oct 23, 2024

Choose a reason for hiding this comment

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

I think we need to be very careful here. Are we referring to msg.sender (which can exist at multiple layers when internal transaction are present), or the from param in a transaction/ transaction receipt? In solidity this is technically the tx.origin

Copy link
Collaborator

Choose a reason for hiding this comment

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

Explicitly we should refer to this as from - we don't want the msg.sender confusion occurring in any external facing docs/comments

Copy link
Collaborator

@Quazia Quazia left a comment

Choose a reason for hiding this comment

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

Small nits 💜

@@ -516,6 +519,29 @@ export class EventAction extends DeployableTarget<
params: ValidateActionStepParams,
): Promise<Address | undefined> {
const signature = claimant.signature;

// find message sender and return it
// WARNING: this is error prone in bridged transactions, as from will be exit node
Copy link
Collaborator

Choose a reason for hiding this comment

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

bridged transactions and SCW transactions

@@ -482,6 +483,8 @@ export class EventAction extends DeployableTarget<
/**
* Derives the action claimant address from a transaction based on the provided ActionClaimant configuration.
* This method supports both event-based and function-based claimant derivation.
* **Important**: The claimant is considered to be `msg.sender` or `transaction.from` when `claimant.signature` is `zeroHash` or `claimant.fieldIndex` is 255.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's tighten this up to explicitly transaction.from since it's technically not msg.sender


// find message sender and return it
// WARNING: this is error prone in bridged transactions, as from will be exit node
if (signature === zeroHash || claimant.fieldIndex === 255) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think claimant.fieldIndex === 255 wll be more consistent since signature === zeroHash will be default state. Unless there's a reason we need to support both. Feels less error prone.

@sammccord
Copy link
Contributor Author

Warnings
⚠️

By using the [ADHOC] title prefix, you are bypassing best practice protections.

Generated by 🚫 dangerJS against 9592dc5

@sammccord
Copy link
Contributor Author

Warnings
⚠️

By using the [ADHOC] title prefix, you are bypassing best practice protections.

Generated by 🚫 dangerJS against 230780e

@sammccord sammccord merged commit 0101059 into main Oct 23, 2024
6 checks passed
@sammccord sammccord deleted the sam/adhoc-msgsender-claimant branch October 23, 2024 18:54
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.

3 participants