About resolving bugfix issue on github

OSS Product Help LangGraph
1

Here is an issue I made in github more then a week ago. It’s quite simple issue - while rendering graph using draw_mermaidand Command, Command[Literal[...] | Literal[...]] is not treated properly unlike standard Command[Literal[..., ...]].

There are some case where you have to make Literal[...] as constant, and append as needed, like Comman[CONSTNAT | Literal[...]], so I believe it might be nice addition to the LangGraph - And according to python typing document, those should work same - I know it doesn’t mean it have to be same in every use case, but people will intuitively think it should work, when in reality, it doesn’t, so I reported it as bug (More specifically at the issue).

It is not that hard issue, so after I uploaded this on github, people kindly made simple patch to resolve this issue (and something like this).

Actually, there are 4 of them (as for today) - 4 PRs. Namely #8370, #8376, #8445, and #8454. And none of them is merged, assigned, nor maintainer gave some kind of interest in this issue, and in this point I believe this count will ever-increase if no action from maintainer is given to this.

I don’t think this is the only issue suffering for lack of interest of maintainer - please close the issue if this one will not be resolved, show some kind of interest - like, even a simple comment like ‘Will be fixed some day, but is quite busy right now’, or review, assign, and approve the PR.

2

This isn’t abandoned, LangGraph auto-closes external PRs until a maintainer assigns the issue. That’s why #8370, #8376, #8445, and #8454 all closed. The bug is still open: #8369.

Workaround for now: annotate with a single multi-value Literal:

def node(state) -> Command[Literal["a", "b"]]:

Avoid Command[Literal["a"] | Literal["b"]] and Command[Literal["a"]] | Command[Literal["b"]] until the fix lands, those don’t infer destinations correctly for Mermaid.

Once someone is assigned on #8369, one of those PRs can reopen. Best next step is a short bump on the issue asking for assignment, not opening more PRs.

3

I mean, more than a week passed and no maintainer gave a slight interest - it is really easy to think this one is abandoned for a week by maintainer. 24 issues added after I submitted, and by tomorrow my issue will be in 2nd page.

About workaround, I know that is standard way. But, as I wrote in issue - consider I have ["coordinator", "processor"] as team member. I want to use this list (which might change in the future) in both type-checking and code (I saw something like this in LangManus).

To make it type-safe (LangManus used Command[Literal[*team_member, "b"]] but my type checker didn’t like this), I might try this:

TEAM_MEMBER: Literal[str] = ["coordinator", "processor"]
team_member_list = list(get_args(TEAM_MEMBER))

def coordinator() -> Command[TEAM_MEMBER | "__end__"]: ...

…Which draw_mermaid doesn’t like.

I didn’t open PR, people just came in and make patch for this. I know someone might assigned on my issue and PR can be opened, but 471 PRs are closed due to not assigned, oldest one being #7264, opened in March 24th (which fixes #7034 which is still opened).

I really hope someone to be assigned on this issue.

4

Hey, @dhnam!

I know it’s frustrating when your bug report has not been acknowledged. We’re doing our best to keep up with the volume of issues on GitHub.

It is a challenge that almost every popular open-source project is facing right now. We appreciate your patience.

Your issue is valid and seems fairly easy to fix. I’ll see what I can do to get this to the right team. Thank you for reporting it!