docs: riverpro missing line type workflows -> workflow #546
Comments
|
Thanks Hubert! Wow, believe it or not, we've had multiple people run through those steps already, but you're the first to report the problem to us :/ I just pushed a fix. We should really also have some basic Levenshtein distance check that'd be able to detect a one letter difference and suggest a correction too. I'll look into that separately. Please don't hesitate to open any more bug reports if you find other problems! |
|
Sure, I was quite surprised that nobody ran into trouble with this one. Awesome it is fixed so fast. I'll open issues as they raise. I actually have one more already. |
brandur
added a commit
that referenced
this issue
Aug 23, 2024
…ein distance This is related to #546. That was a documentation problem, but there are some code problems that are related. The first is that an unknown migration line is a panic in the CLI. This is a byproduct of the fact that `rivermigrate.New` checks the migration line name, but doesn't return an error, so it'd panic instead. Here, I'm suggesting that we do a small breaking change by having `rivermigrate.New` return a possible error. It's not great, but it's something that'll easy for people to fix, and might help avoid some future panics. An alternative possibility would be to add a new `NewWithError` or something of that nature, but it'd make the API a little uglier. Along with that change, we also bring in a change to suggest migration lines in case of an unknown one using Levenshtein distances. This is aimed at preventing totally unactionable errors in the event of very simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually already has a similar feature built-in for command misspellings. I vendored in this repo [1] as a Levenshtein implementation and did a little code clean up. I don't want to add another Go module dependency for such a simple algorithm (it's just a dozen lines), and I believe their MIT license should be compatible. [1] https://github.com/agnivade/levenshtein/tree/master
|
Going to try and do one other small follow up here to suggest alternatives when a migration line is found to be non-existent in #558. |
brandur
added a commit
that referenced
this issue
Aug 23, 2024
…ein distance This is related to #546. That was a documentation problem, but there are some code problems that are related. The first is that an unknown migration line is a panic in the CLI. This is a byproduct of the fact that `rivermigrate.New` checks the migration line name, but doesn't return an error, so it'd panic instead. Here, I'm suggesting that we do a small breaking change by having `rivermigrate.New` return a possible error. It's not great, but it's something that'll easy for people to fix, and might help avoid some future panics. An alternative possibility would be to add a new `NewWithError` or something of that nature, but it'd make the API a little uglier. Along with that change, we also bring in a change to suggest migration lines in case of an unknown one using Levenshtein distances. This is aimed at preventing totally unactionable errors in the event of very simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually already has a similar feature built-in for command misspellings. I vendored in this repo [1] as a Levenshtein implementation and did a little code clean up. I don't want to add another Go module dependency for such a simple algorithm (it's just a dozen lines), and I believe their MIT license should be compatible. [1] https://github.com/agnivade/levenshtein/tree/master
brandur
added a commit
that referenced
this issue
Aug 23, 2024
…ein distance This is related to #546. That was a documentation problem, but there are some code problems that are related. The first is that an unknown migration line is a panic in the CLI. This is a byproduct of the fact that `rivermigrate.New` checks the migration line name, but doesn't return an error, so it'd panic instead. Here, I'm suggesting that we do a small breaking change by having `rivermigrate.New` return a possible error. It's not great, but it's something that'll easy for people to fix, and might help avoid some future panics. An alternative possibility would be to add a new `NewWithError` or something of that nature, but it'd make the API a little uglier. Along with that change, we also bring in a change to suggest migration lines in case of an unknown one using Levenshtein distances. This is aimed at preventing totally unactionable errors in the event of very simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually already has a similar feature built-in for command misspellings. I vendored in this repo [1] as a Levenshtein implementation and did a little code clean up. I don't want to add another Go module dependency for such a simple algorithm (it's just a dozen lines), and I believe their MIT license should be compatible. [1] https://github.com/agnivade/levenshtein/tree/master
brandur
added a commit
that referenced
this issue
Aug 23, 2024
…ein distance This is related to #546. That was a documentation problem, but there are some code problems that are related. The first is that an unknown migration line is a panic in the CLI. This is a byproduct of the fact that `rivermigrate.New` checks the migration line name, but doesn't return an error, so it'd panic instead. Here, I'm suggesting that we do a small breaking change by having `rivermigrate.New` return a possible error. It's not great, but it's something that'll easy for people to fix, and might help avoid some future panics. An alternative possibility would be to add a new `NewWithError` or something of that nature, but it'd make the API a little uglier. Along with that change, we also bring in a change to suggest migration lines in case of an unknown one using Levenshtein distances. This is aimed at preventing totally unactionable errors in the event of very simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually already has a similar feature built-in for command misspellings. I vendored in this repo [1] as a Levenshtein implementation and did a little code clean up. I don't want to add another Go module dependency for such a simple algorithm (it's just a dozen lines), and I believe their MIT license should be compatible. [1] https://github.com/agnivade/levenshtein/tree/master
brandur
added a commit
that referenced
this issue
Aug 24, 2024
…ein distance This is related to #546. That was a documentation problem, but there are some code problems that are related. The first is that an unknown migration line is a panic in the CLI. This is a byproduct of the fact that `rivermigrate.New` checks the migration line name, but doesn't return an error, so it'd panic instead. Here, I'm suggesting that we do a small breaking change by having `rivermigrate.New` return a possible error. It's not great, but it's something that'll easy for people to fix, and might help avoid some future panics. An alternative possibility would be to add a new `NewWithError` or something of that nature, but it'd make the API a little uglier. Along with that change, we also bring in a change to suggest migration lines in case of an unknown one using Levenshtein distances. This is aimed at preventing totally unactionable errors in the event of very simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually already has a similar feature built-in for command misspellings. I vendored in this repo [1] as a Levenshtein implementation and did a little code clean up. I don't want to add another Go module dependency for such a simple algorithm (it's just a dozen lines), and I believe their MIT license should be compatible. [1] https://github.com/agnivade/levenshtein/tree/master
brandur
added a commit
that referenced
this issue
Aug 24, 2024
…ein distance This is related to #546. That was a documentation problem, but there are some code problems that are related. The first is that an unknown migration line is a panic in the CLI. This is a byproduct of the fact that `rivermigrate.New` checks the migration line name, but doesn't return an error, so it'd panic instead. Here, I'm suggesting that we do a small breaking change by having `rivermigrate.New` return a possible error. It's not great, but it's something that'll easy for people to fix, and might help avoid some future panics. An alternative possibility would be to add a new `NewWithError` or something of that nature, but it'd make the API a little uglier. Along with that change, we also bring in a change to suggest migration lines in case of an unknown one using Levenshtein distances. This is aimed at preventing totally unactionable errors in the event of very simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually already has a similar feature built-in for command misspellings. I vendored in this repo [1] as a Levenshtein implementation and did a little code clean up. I don't want to add another Go module dependency for such a simple algorithm (it's just a dozen lines), and I believe their MIT license should be compatible. [1] https://github.com/agnivade/levenshtein/tree/master
brandur
added a commit
that referenced
this issue
Aug 24, 2024
…ein distance (#558) This is related to #546. That was a documentation problem, but there are some code problems that are related. The first is that an unknown migration line is a panic in the CLI. This is a byproduct of the fact that `rivermigrate.New` checks the migration line name, but doesn't return an error, so it'd panic instead. Here, I'm suggesting that we do a small breaking change by having `rivermigrate.New` return a possible error. It's not great, but it's something that'll easy for people to fix, and might help avoid some future panics. An alternative possibility would be to add a new `NewWithError` or something of that nature, but it'd make the API a little uglier. Along with that change, we also bring in a change to suggest migration lines in case of an unknown one using Levenshtein distances. This is aimed at preventing totally unactionable errors in the event of very simple misspellings (e.g. "workflow" versus "workflows"). Cobra actually already has a similar feature built-in for command misspellings. I vendored in this repo [1] as a Levenshtein implementation and did a little code clean up. I don't want to add another Go module dependency for such a simple algorithm (it's just a dozen lines), and I believe their MIT license should be compatible. [1] https://github.com/agnivade/levenshtein/tree/master
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
When I run cli with
--line workflowsit panics.But with
--line workflowall is goodLinks with typos
https://riverqueue.com/docs/pro/go-proxy#installing-in-ci-and-build-environments
https://riverqueue.com/docs/pro/getting-started#running-pro-migrations
The text was updated successfully, but these errors were encountered: