Enhance manual retry state functionality by adding 'manul_retry_fanout_id'

[NiveditJain]

Field and updating related logic. This change ensures better tracking of manually retried states and improves the overall state management process.

Majorly this fixes bugs with unites.

[coderabbitai]

Warning

Rate limit exceeded

@NiveditJain has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 15 minutes and 52 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between ed58aef and 423bb34.

📒 Files selected for processing (2)

• state-manager/app/controller/manual_retry_state.py (1 hunks)
• state-manager/app/models/db/state.py (2 hunks)

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

📝 Walkthrough

Summary by CodeRabbit

• New Features
  • Captures the originating fanout ID when creating a manual retry, improving traceability across retries.
• Improvements
  • State fingerprinting now includes the manual retry fanout ID, enhancing uniqueness and reducing unintended deduplication or merges during manual retries.

Walkthrough

Adds a new manual_retry_fanout_id field to the State model, passes it from the manual retry controller using body.fanout_id, and includes the field in the fingerprint generation payload.

Changes

Cohort / File(s)	Summary
Manual Retry Controller state-manager/app/controller/manual_retry_state.py	Passes manual_retry_fanout_id=body.fanout_id when constructing State for manual retries; minor argument formatting adjustment.
State Model and Fingerprint state-manager/app/models/db/state.py	Adds State.manual_retry_fanout_id: str with default ""; extends fingerprint payload to include manual_retry_fanout_id.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    actor U as User/Caller
    participant C as ManualRetryController
    participant S as State(Model)
    participant F as Fingerprint Logic
    participant D as DB

    U->>C: Request manual retry (fanout_id)
    C->>S: State(..., manual_retry_fanout_id=fanout_id)
    S->>F: Build fingerprint payload (includes manual_retry_fanout_id)
    F-->>S: Fingerprint value
    S->>D: Persist State with manual_retry_fanout_id and fingerprint
    D-->>C: Save result
    C-->>U: Response

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

A hop, a bop, a fanout tag in tow,
I stash it in my State burrow below.
Fingerprints updated, whiskers aligned—
Retries now remember the trail we’ve signed.
Thump-thump! Into the DB I go—
Carrot-commits crisp, review set to low. 🥕🐇

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title describes the main intent of the change (adding a field to improve manual retry state tracking) and therefore is related to the changeset, but it contains a clear typo in the field name ("manul_retry_fanout_id" vs "manual_retry_fanout_id"), which reduces clarity though does not make it incorrect about the primary change.
Description Check	✅ Passed	The description is on-topic: it states a field was added and related logic updated to improve tracking of manually retried states and claims to fix bugs with "unites", which aligns with the provided change summary (addition of manual_retry_fanout_id and updates to constructor and fingerprint logic); it is terse but not unrelated.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Summary of Changes

Hello @NiveditJain, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request enhances the system's ability to manage and track manually retried states by introducing a dedicated identifier, 'manul_retry_fanout_id'. This new field is integrated into the state creation process and its unique fingerprint generation, which is designed to improve overall state management, prevent unwanted retries, and resolve existing bugs related to 'unites' by providing more precise state identification.

Highlights

• New Field Introduction: A new field, 'manul_retry_fanout_id', has been added to the State database model to specifically track fanout IDs for manually retried states.
• Manual Retry Logic Update: When a state is manually retried, the 'manul_retry_fanout_id' is now populated with the provided 'fanout_id', ensuring better traceability for these specific retries.
• State Fingerprint Enhancement: The 'manul_retry_fanout_id' is now included in the state's fingerprint generation, which is crucial for maintaining uniqueness and preventing unintended duplicate states, particularly addressing issues with 'unites'.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new field manul_retry_fanout_id to the State model to better track manually retried states, and includes this field in the state's fingerprint calculation. The overall logic is sound and addresses the goal described. However, there is a consistent typo ('manul' instead of 'manual') in the new field name across all modified files. I've identified this as a high-severity issue, as it affects the database model, and have provided suggestions to correct it for code clarity and long-term maintainability.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[NiveditJain]

/gemini review

[NiveditJain]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[gemini-code-assist]

Code Review

This pull request introduces a manual_retry_fanout_id field to the State model to correctly handle manual retries of 'unite' states. The new field is incorporated into the state fingerprint calculation, which resolves a bug that prevented retrying unite nodes due to unique constraint violations. The logic in the manual_retry_state controller is updated to set this new field.

The changes are logical and address the described problem. I have a couple of suggestions to improve code clarity and maintainability by refining a field description and adding a comment.

Additionally, the unit tests have not been updated to verify that the new manual_retry_fanout_id field is set correctly. It's important to update tests, especially test_manual_retry_state_with_complex_inputs_and_parents which already tests with does_unites = True, to assert the value of this new field.

P.S. There seems to be a small typo in the pull request title ('manul' instead of 'manual').

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between cfb2130 and ed58aef.

📒 Files selected for processing (2)

• state-manager/app/controller/manual_retry_state.py (1 hunks)
• state-manager/app/models/db/state.py (2 hunks)

🔇 Additional comments (2)

state-manager/app/models/db/state.py (1)

46-47: Including manual_retry_fanout_id in the fingerprint is sensible; verify intended dedupe behavior.

This will change the fingerprint for uniting states on manual retries. Confirm whether you want dedupe per original state (use original state’s fanout_id) or per manual request (use body.fanout_id). Implementation should match the chosen semantics.

state-manager/app/controller/manual_retry_state.py (1)

33-35: Align manual_retry_fanout_id with intended meaning (original state vs request token)

state-manager/app/controller/manual_retry_state.py:33–35 — both fanout_id and manual_retry_fanout_id are assigned from body.fanout_id. If manual_retry_fanout_id should link to the state being retried, assign it from state.fanout_id; otherwise update the model/field docs to state it is a request-level ID and validate body.fanout_id (non-empty, UUID-like) or generate a server UUID when absent.

Proposed fix:

-                fanout_id=body.fanout_id, # this will ensure that multiple unwanted retries are not formed because of index in database
-                manual_retry_fanout_id=body.fanout_id
+                fanout_id=body.fanout_id, # ensures idempotency for a given manual retry request
+                manual_retry_fanout_id=state.fanout_id  # links back to the original state being retried

Repository search returned no matches (ripgrep skipped files). Verify all usages of manual_retry_fanout_id and fanout_id across the codebase and update callers/models accordingly.