If this check fails due to a typo in specifying the required resource key from the user's end,
this will display all the possible resources they can choose from or prompts the user
to define the actual resource for the selected mode.
Details
Details
tbd
Diff Detail
Diff Detail
- Repository
- R1 dagster
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
In cases where we're reasonably sure someone made a typo; i think it makes sense to communicate that there's a resource key that is similar to the one they provided. In the general case of someone missing a resource however, I'm not sure what the benefit of displaying keys is, however. Would the intention be that someone could see which resource keys are available, and change their definition to use that resource key instead? If that's the case, I think we might want to orient the language more around resource keys than definitions, since that's what we would expect people to be switching around.
| python_modules/dagster/dagster/core/definitions/pipeline.py | ||
|---|---|---|
| 652 | nit: OutputManagerDefinition subsumes IOManagerDefinition. I think it's fine to keep it as just IOManagerDefinition | |
Comment Actions
either re-orienting language around providing resource for resource key / switching resource key, or some sort of levenshtein distance "did you mean __?" error message (not sure if we have a precedent for something like this in the codebase yet)
Comment Actions
@cdecarolis I think there are two cases here:
- They used the wrong resource key in their solid definition (it's a typo)
- They used the correctly intended resource key, but the resource key is not defined in their mode yet.
Since we can't tell which case it is, the error message isn't prescriptive on what should be changed. But adding that the resource "must be defined" solves for case (2), and showing the possible resources that are available solves for case (1) as they can see they misspelled the resource key compared to what they provided.