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.

Sign up for GitHub

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

Jump to bottom

Distinguish between object owner and account owner in Owner type #559

Closed
lxfind opened this issue Feb 24, 2022 · 1 comment
Closed

Distinguish between object owner and account owner in Owner type #559

lxfind opened this issue Feb 24, 2022 · 1 comment
Assignees
@lxfind
Labels
sui-node Type: Enhancement New feature or request
Milestone
[A] Internal Testing

Comments

@lxfind
Copy link
Contributor

lxfind commented Feb 24, 2022

Leftovers from #549.

There is value in knowing whether an object is owned by an address or another object. E.g., if the wallet is trying to construct a tx thats uses o, it can decide to proceed differently when o.owner is an address (check if the wallet has the key for that address) vs when o.owner is an object (will need to also include the owner object in this tx, and recursively figure out whether it can use the owner object).
@lxfind lxfind mentioned this issue Feb 24, 2022
Merged
@sblackshear sblackshear added the Type: Enhancement New feature or request label Mar 1, 2022
@gdanezis gdanezis mentioned this issue Apr 19, 2022
Closed
@gdanezis gdanezis added this to the DevNet milestone Apr 19, 2022
@todd-mystenlabs todd-mystenlabs modified the milestones: DevNet, Pre Testnet Apr 21, 2022
@lxfind
Copy link
Contributor Author

lxfind commented Apr 21, 2022

Turns out this is already done. Owner currently have AddressOwner and ObjectOwner

@lxfind lxfind closed this as completed Apr 21, 2022
mwtian pushed a commit that referenced this issue Sep 12, 2022
@huitseeker
fix: Avoid spammy logging on hitting the entwork's BoundedExecutor (#763
801f306 
)

We operate an executor with a bound on the concurrent number of messages (see #463, #559, #706).
PR #472 added logging for the bound being hit.

We expect the executors to operate for a long time at this limit (e.g. in recovery situation).
The spammy logging is not usfeful

This removes the logging of the concurrency bound being hit.
Fixes #759
mwtian pushed a commit to mwtian/sui that referenced this issue Sep 29, 2022
@huitseeker
fix: Avoid spammy logging on hitting the entwork's BoundedExecutor (M…
4fcbf7b 
…ystenLabs#763)

We operate an executor with a bound on the concurrent number of messages (see MystenLabs#463, MystenLabs#559, MystenLabs#706).
PR MystenLabs#472 added logging for the bound being hit.

We expect the executors to operate for a long time at this limit (e.g. in recovery situation).
The spammy logging is not usfeful

This removes the logging of the concurrency bound being hit.
Fixes MystenLabs#759
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lxfind lxfind

Labels
sui-node Type: Enhancement New feature or request
Projects
None yet
Milestone
[A] Internal Testing
Development

No branches or pull requests
4 participants
@lxfind @sblackshear @gdanezis @todd-mystenlabs