ls-apis choking on the latest dpd-client #7853
Conversation
| } | ||
| if found_in_workspaces[1].0.name() == "omicron" { | ||
| return Ok(found_in_workspaces[1]); | ||
| if server_pkgname == "dpd-client" && found_in_workspaces.len() == 3 { |
There was a problem hiding this comment.
I wonder if we really should keep the length check here, or just remove it --- do we want to have to update this again when the fourth dpd-client shows up?1 Since we are always deciding to just return the dependency in this workspace, should we just do that unconditionally regardless of the number of workspaces? Or, do you think that having to bump up the 3 to 4 is a useful enough signal that we want this to break?
Footnotes
-
Not that i think this is apt to happen imminently, but, like...it kind of feels like by the time something has happened three times, you gotta be prepared for it to happen any number of times. ↩
There was a problem hiding this comment.
Good question. I think it makes sense to keep it. I'm glad I looked at this one and determined that yes, this is a new package called this and not some other strangeness that we didn't anticipate.
|
The underlying problem here was resolved by #7907! 🎉 |
Fixes #7847.
This isn't a great situation but it was already a problem before and I've extended the existing workaround for this problem.
I'm not sure what the best longer-term answer is here. Maybe we should treat apparently-distinct client packages having the same name as equivalent? Or maybe we should put the dpd OpenAPI document and its client package into its own public repo so that we don't generate many distinct Rust packages for the client?