Hey guys, where/how does exactly the partition_fn ...
# deployment-kubernetes
Hey guys, where/how does exactly the partition_fn gets run? I have defined a partition_fn that queries my database and returns a list of company names to be used as Partitions and when running this locally my partition set is properly generated and I am able to run backfills. However, when I deploy to k8s and attempt to run a backfill I get the following error (which is somewhat generic):
Copy code
AttributeError: 'ExternalPartitionExecutionErrorData' object has no attribute 'partition_names'
  File "/usr/local/lib/python3.7/site-packages/dagster_graphql/implementation/utils.py", line 14, in _fn
    return fn(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/dagster_graphql/implementation/fetch_partition_sets.py", line 221, in get_partition_set_partition_statuses
    for partition_name in result.partition_names
I have installed the helm chart using a custom service account binded to a Workload Identity that has access to my database, so I should be able to query the database from anywhere (dagster daemon, dagit, run jobs, etc.). I believe this has nothing to do with permissions, but may have something to do with the ENV variables defined in a configmap that are only mapped to my user deployment (hence the question about where it is being run)
Hi Ruben - partition_fn will execute in your user code deployment (the same place dagit loads your pipeline code from). It looks like you're running into a place where we're not handling errors correctly (cc @prha re: backfill callsite), or we'd be able to see what exactly the error is
Yeah, I got the same error locally when I was wrongly generating the list of partitions, but managed to fix it so that it worked locally. I'm sure this is a different error now but I can't tell
I'll file an issue for the error handling piece
Thanks Daniel
Although I cannot tell due to the generic error, I believe my issue is related to this https://github.com/dagster-io/dagster/issues/3934 since my dagster-user-deployments sub chart is not inheriting the serviceAccount from the helm chart and is instead using the default one
the issue should be resolved - you can set
in the parent chart to ensure that the subchart references the service account that you want
Yeah, you are right Rex, we hadn't upgraded to 0.11.2 so we didnt use this yet. Thanks!