fix(generator): handle indirect recursion via DFS cycle detection

[raushan728]

• Fix: Added DFS-based cycle detection in util.py to identify indirect type cycles (e.g., A -> B -> A).
• Boxing: Recursive references are now correctly wrapped in Option<Box<T>>.
• Tests: Added unit tests in util_test.py for cycle detection and type shape verification.
• Impact: Unblocks slides, chat, analyticsadmin, and dialogflow APIs.

[Byron]

Thanks for contributing, but please do remove the generated code (the one generated in the traditional sense at least).

[raushan728]

thanks for the feedback @Byron!

i have Removed all generated code from the PR as requested. plz take a look

[Copilot]

Pull request overview

Adds indirect-recursion detection to the Rust type generator so recursive schema references can be boxed to avoid Rust “infinite size” type errors, and updates the shared API blacklist accordingly.

Changes:

• Introduces DFS-based reference traversal helpers (get_all_refs, points_to) to detect indirect recursion cycles.
• Updates $ref handling in to_rust_type_inner() to box references participating in detected cycles.
• Removes several APIs from etc/api/shared.yaml blacklist (previously excluded due to recursive-type generation failures).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/generator/lib/util.py	Adds DFS reachability checks and applies them during $ref type generation to break indirect recursion cycles.
etc/api/shared.yaml	Unblacklists multiple APIs that were previously excluded due to recursive-type generation issues.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Byron]

Thanks a lot, I think this is a great improvement!

A few things to change came up, let's resolve them and merge.

[raushan728]

@Byron everything is updated u can review it now. If this any problems, plz leave a comment.

[Byron]

Great, thanks a lot!

I am now running make cargo-api ARGS=check locally and will merge if it all passes.

Tasks

• update all APIs

[raushan728]

Thanks for merging the PR, @Byron! It was great working on this.

While diving into the generator code, I noticed a couple of other improvements that could be valuable:

1. Builder Ergonomics: Changing setters to accept impl Into<String>. This would make the library much more idiomatic and easier to use by removing the need for manual .to_string() calls.
2. Error Handling: Modernizing the google-apis-common crate by adopting thiserror for cleaner and more maintainable error definitions.

Let me know if you’d like me to open Pull Requests for these as well. I'd be happy to contribute further!

[Byron]

Thanks for offering, it's much appreciated.

1. I think we should do, even though that convenience will be paid for with larger binaries. But that's fine for now, and there are mitigations that can be implemented if needed.
2. Modernising errors, yes, please, but not with thiserror. And the motivation should be something graspable, like making it possible to know if the error is permanent or transient.

[Byron]

Oh, and lastly, if you use AI please give it a Co-authored-by field. I am trying to make AI transparent across my projects. Thanks for considering.

[raushan728]

Thanks for the feedback, @Byron!

I’m a 2nd-year student and I use AI to help with research, project summaries, and refining my technical discussions. I'll make sure to include the Co-authored-by tag in future commits for transparency.

I'll focus on the ergonomic improvements next without using thiserror. Please let me know if you have any other concerns!

[raushan728]

Submitted two PRs regarding our discussion. I’ll keep watch for any comments. Thanks, @Byron