This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

This PR was closed accidentally while I was trying to convert it to draft. The branch and commits are still available.

Could a maintainer please reopen this PR, or advise whether I should open a new draft PR from the same branch?

The change addresses #4191 and is intended for API discussion and GPU CI validation before being marked ready for review.

/ok to test

/ok to test

@alexbarghi-nv, there was an error processing your request: E1

See the following link for more information: https://docs.gha-runners.nvidia.com/cpr/e/1/

/ok to test 62e035b

Hi @alexbarghi-nv, just checking whether the CI run for commit 62e035b needs to be retriggered. Please let me know if anything is needed from my side.

Always excited for external contributions, thanks!

There are format issues with your PR that should be fixed, you should be able to follow the links to see them. I think if you enable pre-commit hooks you should be able to let the tools do much of the work for you.

Thank you for the guidance. I have applied the repository Python formatting fixes in the latest commit b2454a1. Please let me know if any further changes are needed.

/okay to test b2454a1

/okay to test c26adda

Hi, thanks for the review. I addressed the requested changes and updated the PR. The style checks and build jobs are now passing. I’m currently investigating the remaining Python 3.12 CI failure (conda-python-tests / 13.0.3, 3.12, amd64, ubuntu24.04) and will update the PR once I identify the root cause. Please let me know if you notice anything specific that I should look at.

I reviewed the Python 3.12 CI logs. The remaining failure is in tests/utils/test_dataset.py::test_benchmarking_datasets[dataset4] and is caused by urllib.error.URLError: No address associated with hostname. This appears to be an external dataset download/DNS issue and does not seem related to the changes in this PR. All other tests in the job passed.

Hi @rlratzel, just checking in on the review when convenient. Please let me know if any additional information or changes are needed from my side.

Thanks for your contribution @sauravsingla . I think the PR changes look technically fine, but I'm wondering if having a completely different return type is expected when return_offsets=True - I think a user of this API would be surprised if a Graph object is not returned.

That said, I'm not opposed to this change, I just want to make sure these aspects have been discussed. Also, would simply using pylibcugraph directly for your use case be an option instead?

Thanks for the thoughtful review!

For my own use case, calling pylibcugraph directly is certainly an option. My motivation for this PR was broader: to make the same capability available through the high-level cugraph API so users don’t need to drop down to the lower-level interface to work with multi-seed ego graphs.

Regarding the return type, I agree that returning something other than a Graph when return_offsets=True could be surprising. I chose (edge_dataframe, offsets) because the offsets returned by pylibcugraph directly delimit contiguous ranges in the returned edge output, so that representation preserves the meaning of the offsets naturally.

My intention wasn’t to introduce a different API pattern, but to expose the existing functionality while preserving the per-seed boundaries. If maintaining a Graph return type is the preferred direction for the public API, I’m happy to revise the implementation to align with the project’s conventions. I’d appreciate your guidance on the API shape you think would best fit cuGraph.