add get_batch_create_async_status

[shuaitseng]

Important

Add get_batch_create_async_status function to Tasks class for checking async batch task creation status, update version to 1.2.0.

• Behavior:
  • Adds get_batch_create_async_status function to Tasks class in tasks.rb to retrieve status of asynchronous batch task creation.
• Documentation:
  • Updates CHANGELOG.md to include get_batch_create_async_status endpoint.
  • Adds get_batch_create_async_status to task operations in README.md and README.es.md.
• Versioning:
  • Bumps version to 1.2.0 in package.json and ruby-onfleet.gemspec.

^{This description was created by for 81eb8d4. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

PR Summary

This pull request adds a new method get_batch_create_async_status to the Tasks resource in the ruby-onfleet library.

Changes:

• Adds a method that allows clients to check the status of asynchronous batch task creation operations
• The method accepts configuration parameters and an ID to construct the appropriate endpoint
• Uses a GET request to retrieve the current status of the batch operation

This enhancement will be useful for applications that need to monitor the progress of large batch task creation operations without blocking until completion.

[ellipsis-dev]

⚠️ This PR modifies application logic but lacks adequate unit test coverage. Please ensure all new logic is tested.

I noticed that you've added a new method get_batch_create_async_status to the tasks.rb file, which is part of the application's core functionality. This method implements API logic to check the status of batch task creation.

According to our development guidelines, new application logic should be accompanied by appropriate unit tests to ensure the functionality works as expected and continues to work in the future.

Could you please add unit tests for this new method? This will help maintain the quality and reliability of the codebase.

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to b61ff5a in 36 seconds. Click for details.

• Reviewed 18 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. lib/resources/tasks.rb:32

• Draft comment:
  Consider adding a brief comment explaining what get_batch_create_async_status does (e.g., retrieving the status of an asynchronous batch create) to aid maintainability.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

2. lib/resources/tasks.rb:34

• Draft comment:
  Verify that the endpoint path 'tasks/batch/#{id}' is correct per API specifications. It may be worth double-checking if it should align with the 'batch-async' naming convention used elsewhere.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 40% <= threshold 50% The comment is asking the PR author to verify the endpoint path, which violates the rule against asking the author to confirm or double-check things. However, it does provide a specific suggestion about aligning with a naming convention, which could be useful.

Workflow ID: wflow_7kwVBDeAETZPjnoP

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[gonzalogrisafi]

LGTM!

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 81eb8d4 in 2 minutes and 44 seconds. Click for details.

• Reviewed 82 lines of code in 5 files
• Skipped 0 files when reviewing.
• Skipped posting 2 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. CHANGELOG.md:8

• Draft comment:
  The release date for version 1.2.0 in the CHANGELOG (2024-10-29) does not match the date in ruby-onfleet.gemspec (2025-10-29). Please align these dates.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This comment identifies a real inconsistency between the CHANGELOG and gemspec files. The dates should match for the same version release. The comment is actionable - it suggests changing 2024-10-29 to 2025-10-29 in the CHANGELOG. This is about code that was changed in the diff (the new 1.2.0 entry was added). However, I need to consider: is this cross-file issue? The rules say "Ignore cross-file issues. Only think about the file you are reviewing." This is a cross-file consistency check, which technically violates that rule. But the comment is on CHANGELOG.md and suggests fixing CHANGELOG.md, so it's really about making this file correct, not about the other file. The rules explicitly state "Ignore cross-file issues. Only think about the file you are reviewing." This comment requires knowledge of another file (ruby-onfleet.gemspec) to validate the issue. Without seeing the gemspec file, we wouldn't know there's a problem with the CHANGELOG date. This is a cross-file consistency check. While this is technically a cross-file issue, the comment is actionable and points to a specific fix in the file being reviewed. The date inconsistency is a real problem that could cause confusion. However, the rule about ignoring cross-file issues is explicit and takes priority. The reviewer shouldn't need to check other files to validate changes in this file. Despite being a valid observation about a date inconsistency, this comment violates the explicit rule to ignore cross-file issues. The comment requires knowledge of ruby-onfleet.gemspec to determine which date is correct, making it a cross-file consistency check that should be deleted.

2. README.md:199

• Draft comment:
  Typo: 'get_delivery_manfiest' should be corrected to 'get_delivery_manifest'.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_GnJKuXMLwUgVt15k

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}