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

Add result_quantity to open_until #6290

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

TastyPumPum
Copy link
Contributor

@TastyPumPum TastyPumPum commented Jan 17, 2025

  • I have tested all my changes thoroughly.

Important

Add result_quantity option to openCommand to specify target item count before stopping, with handling in abstractedOpenUntilCommand.

  • Behavior:
    • Add result_quantity option to openCommand in open.ts to specify target item count before stopping.
    • Update abstractedOpenUntilCommand in openCommand.ts to handle result_quantity, breaking loop when target count is reached.
  • Validation:
    • Ensure result_quantity is a positive integer in abstractedOpenUntilCommand.
  • Misc:
    • Adjust loop limit in abstractedOpenUntilCommand to 10000 for opening items.

This description was created by Ellipsis for 1053dc6. It will automatically update as commits are pushed.

@TastyPumPum

This comment was marked as off-topic.

This comment was marked as off-topic.

@TastyPumPum

This comment was marked as off-topic.

Copy link
Contributor

@ellipsis-dev ellipsis-dev bot 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 to me! Reviewed everything up to 1053dc6 in 36 seconds

More details
  • Looked at 125 lines of code in 2 files
  • Skipped 0 files when reviewing.
  • Skipped posting 1 drafted comments based on config settings.
1. src/mahoji/lib/abstracted_commands/openCommand.ts:65
  • Draft comment:
    Consider adding a check to see if the user already owns the openUntil item and handle it appropriately, possibly with a confirmation prompt.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable:
    The code previously had this check but it was deliberately removed in this PR. The change to support multiple quantities suggests this check is no longer relevant - users may want multiple copies of items. The removal seems intentional based on the other changes. Making this suggestion would be going against an explicit design decision.
    Maybe there are some items that still shouldn't be duplicated even with the new multiple quantity feature? The original check was specifically for clue items.
    The PR author explicitly removed this check while adding quantity support. If certain items need special handling, that should be a separate feature request with specific requirements, not a vague suggestion to add back removed code.
    Delete this comment as it suggests reverting an intentional change without strong justification.

Workflow ID: wflow_wRu3B50SNC4pIPi1


You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

Comment on lines 6 to 19
export const RawSQL = {
updateAllUsersCLArrays: () => `UPDATE users
SET ${u.cl_array} = (
SELECT (ARRAY(SELECT jsonb_object_keys("${u.collectionLogBank}")::int))
)
WHERE last_command_date > now() - INTERVAL '1 week';`,
SET ${u.cl_array} = (
SELECT ARRAY(SELECT jsonb_object_keys("${u.collectionLogBank}")::int)
)
WHERE last_command_date > now() - INTERVAL '1 week';`,

updateCLArray: (userID: string) => `UPDATE users
SET ${u.cl_array} = (
SELECT (ARRAY(SELECT jsonb_object_keys("${u.collectionLogBank}")::int))
)
WHERE ${u.id} = '${userID}';`
SET ${u.cl_array} = (
SELECT ARRAY(SELECT jsonb_object_keys("${u.collectionLogBank}")::int)
)
WHERE ${u.id} = '${userID}';`
};

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is this an intentional change?

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 this was intentional. Some of the openings were not showing to the user, and I was getting this error message logged:
ERROR: operator does not exist: integer[] & integer[]

Removing the extra pair of parentheses and running linting helped resolve the issue and fixed the errors. If you think it's not needed though you can remove these changes.

Copy link
Collaborator

Choose a reason for hiding this comment

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

That error sounds like it may be because you dont have the intarray extension installed on your postgres. Try running CREATE EXTENSION intarray; in your db. I dont see any reason removing parens would fix that error though too, so i would try undo the changes and see if it works without it

Copy link
Contributor

Choose a reason for hiding this comment

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

The issue is when collection log is getting a lot of updates, here because of opening 5000 caskets at once. I guess this might be splitting up the sql lookup, so concatting is required? Bit annoying to require everyone to install sql extensions to setup bot

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