Async task and event loop safety in Megatron Core

[tdene]

What does this PR do ?

Python has several idiosyncrasies when it comes to asyncio. This PR addresses two of them by creating helper methods and establishing foolproof coding philosophy.

The first problematic behavior is that coroutines that run inside a task fail silently, causing an eternal hang. While this is intended, and useful in some programming patterns, in our current usecase of asyncio tasks it does nothing but lead to untraceable silent deadlocks. A common opinion is that handling such behavior in the official, Pythonic, way, causes unnecessary code complication.
This PR's first commit defines a wrapper that, when placed around a coroutine that gets called by a task, makes the coroutine's failure loud and traceable. It is the experience of the Megatron-RL team that this utility can reduce debugging time by days or weeks.

The second problematic behavior is that it is not rare for a running program to involve itself with multiple event loops, if not intentionally, then by accident. The Megatron Inference team has already encountered this issue and dealt with it through a get_asyncio_loop helper. This PR's second commit standardizes the use of this helper across the current asyncio codebase. It also allows for loop objects to be passed around manually; the Megatron-RL team has witnessed that this code pattern greatly simplifies the debugging process.

In addition, this PR's first commit preserves some async logging logic that Megatron-RL development heavily relies on. This logic is optional, and turned off by default.

Contribution process

flowchart LR
    A[Pre-checks] --> B[PR Tests]
    subgraph Code Review/Approval
        C1[Expert Review] --> C2[Final Review]
    end
    B --> C1
    C2 --> D[Merge]

Loading

Pre-checks

• I want this PR in a versioned release and have added the appropriate Milestone (e.g., Core 0.8)
• I have added relevant unit tests
• I have added relevant functional tests
• I have added proper typing to my code Typing guidelines
• I have added relevant documentation
• I have run the autoformatter.sh on my PR

Code review

The following process is enforced via the CODEOWNERS file for changes into megatron/core. For changes outside of megatron/core, it is up to the PR author whether or not to tag the Final Reviewer team.

For MRs into `main` branch

(Step 1): Add PR label Expert Review

(Step 2): Collect the expert reviewers reviews

1. Attach the Expert Review label when your PR is ready for review.
2. GitHub auto-assigns expert reviewers based on your changes. They will get notified and pick up your PR soon.

⚠️ Only proceed to the next step once all reviewers have approved, merge-conflict are resolved and the CI is passing.
Final Review might get declined if these requirements are not fulfilled.

(Step 3): Final Review

1. Add Final Review label
2. GitHub auto-assigns final reviewers based on your changes. They will get notified and pick up your PR soon.

(Optional Step 4): Cherry-pick into release branch

If this PR also needs to be merged into core_r* release branches, after this PR has been merged, select Cherry-pick to open a new PR into the release branch.

For MRs into `dev` branch

The proposed review process for `dev` branch is under active discussion.

MRs are mergable after one approval by either eharper@nvidia.com or zijiey@nvidia.com.

Merging your PR

Any member of core-adlr and core-nemo will be able to merge your PR.

[copy-pr-bot]

/ok to test

@tdene, there was an error processing your request: E1

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

[tdene]

/ok to test 7bc898f

[tdene]

/ok to test

[kvareddy]

@santhnm2 @sidsingh-nvidia @shanmugamr1992 can you please review this MR.

[santhnm2]

LGTM

[tdene]

/ok to test d46b20e

[tdene]

/ok to test c73a802

[tdene]

/ok to test 8f5772b

[tdene]

/ok to test 230e26e