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

feat: tracking undelivered request Ids #11

Merged
merged 8 commits into from
Oct 24, 2023
Merged

feat: tracking undelivered request Ids #11

merged 8 commits into from
Oct 24, 2023

Conversation

kupermind
Copy link
Collaborator

  • Tracking of undelivered request Ids.

/// @title AgentMech - Smart contract for extending ERC721Mech
/// @dev A Mech that is operated by the holder of an ERC721 non-fungible token.
contract AgentMech is ERC721Mech {
event Perform(address indexed sender, bytes32 taskHash);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This event is not used.

Comment on lines +43 to +44
// Map of request Ids
mapping (uint256 => uint256[2]) public mapRequestIds;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

A two-way circular map stores all the undelivered requests and correctly removes elements when requests are delivered.


/// @dev Gets the set of undelivered request Ids.
/// @return requestIds Set of undelivered request Ids.
function getUndeliveredRequestIds() external view returns (uint256[] memory requestIds) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we need to worry about the number of undelivered requests being too large. Although unlikely, I think it may happen. Could that result in a big request to the rpc which would get dropped constantly?
I am thinking maybe it makes sense to either have this method take a maxNumReqs, or have another method that supports that, just to avoid this case.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good point. How about we slightly alter the method to allow to (optionally) set a batch size. Then you can get constant sized returns

Copy link
Collaborator

Choose a reason for hiding this comment

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

@DavidMinarsch that should do

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've accounted for both size and offset, please take a look.

Comment on lines +156 to +164
// If size is zero, return all the requests
if (size == 0) {
size = numRequests;
}

// Check for the size + offset overflow
if (size + offset > numRequests) {
revert Overflow(size + offset, numRequests);
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

We need both size and offset to access any number of requests.

Comment on lines +172 to +175
for (uint256 i = 0; i < offset; ++i) {
// Next request Id of the current element based on the current request Id
curRequestId = mapRequestIds[curRequestId][1];
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Skip the initial offset number of requests.

@kupermind kupermind merged commit ad7de4c into main Oct 24, 2023
2 checks passed
@kupermind kupermind deleted the track_request_ids branch October 24, 2023 11:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants