Open mikolak-net opened 9 months ago
Hi @mikolak-net, will pass this on to the external assets team.
For now, one workaround would be to supply a custom, no-op input manager which will let you keep the dependency between the external asset and the graph-backed-asset but avoid this error:
class NoOpInputManager(ConfigurableIOManager):
def load_input(self, context):
return None
def handle_output(self, context, obj):
pass
@op(ins={"external_asset_in": In(input_manager_key="no_op")})
def retrieve_external_asset_value(
context: OpExecutionContext, external_asset_in
) -> Any:
...
@graph_asset(
ins={"external_asset_in": AssetIn(EXTERNAL_ASSET_KEY)},
auto_materialize_policy=AutoMaterializePolicy.eager(),
)
def graph_asset(
external_asset_in,
) -> str:
return retrieve_external_asset_value(external_asset_in)
...
defs = Definitions(
assets=[external_asset, graph_asset],
sensors=[test_sensor],
resources={"no_op": NoOpInputManager()},
)
@benpankow : oh yeah, that's a considerably less-intrusive workaround in the context of the DAGs, thanks!
Dagster version
dagster, version 1.5.13
What's the issue?
It is not possible for a Graph-Backed Asset to be a direct dependency of an External Asset. Attempting to do so will result in a "bogus" materialization retrieval error.
What did you expect to happen?
Graph-Backed Assets should be able to supply a superset of functionality of
@asset
-based Assets. However, they lack adeps
parameter.How to reproduce?
Launch the included code as a file with
dagster dev
and turn Auto-Materialization on.Running the code will eventually result in an error of the form:
Deployment type
None
Deployment details
No response
Additional information
@asset
-based:deps
parameter.Message from the maintainers
Impacted by this issue? Give it a 👍! We factor engagement into prioritization.