Automate context contains wrong automationID

I am having a small issue with the preset automation context in my python based automation.

I am trying to get the automation results from previous versions and for that i am extracting the automationID from the context. It seems that the automationID is wrong. It is constant between runs but doesn’t correlate to the automationID set after the run finishes.

What i am doing:
I am logging:

def automate_function(
    automate_context: AutomationContext,
    function_inputs: FunctionInputs,
) -> None:
...
logger.info(f"Automation ID: {automate_context.automation_run_data.automation_id}")
...

This gives: “cc992b05d0”

After the automation is finished (or even while it is running) i query the data with:

query AutomationData($modelId: String!, $projectId: String!, $versionId: String!) {
                          project(id: $projectId) {
                            model(id: $modelId) {
                              version(id: $versionId) {
                                automationsStatus {
                                  automationRuns {
                                    functionRuns {
                                      results
                                      status
                                    }
                                    automationId
                                    automation {
                                      id
                                    }
                                  }
                                }
                              }
                            }
                          }
                        }

There the automationId is “012b5d1c5c”

I think this is a bug or maybe I misunderstand what the automate_context.automation_run_data should contain.
This also only happens when the automation is deployed. During local testing the automationId is properly set.

-as a small sidenote:
I had a lot of trouble getting the logs at times. My current browser instance for example randomly stopped working and always reports an error. My colleague is able to retrieve the logs.

1 Like

Thank you for the detailed bug report @Witt . Just a quick heads up to you that I’ll be investigating this for you today.

1 Like

Update: I’ve diagnosed the problem but the solution requires a light dose of design. This is not a simple typo-type bug, unfortunately. You are correct that the local run is provided the automation id you expect, but the deployed run is provided some other unrelated id.

Working on a fix. In the meantime, can you maybe share more about what you’re trying to do with function runs checking results from previous versions? There may be another way to get the information you’re after.

The logs issue has been a bit harder to replicate. Do you happen to get more information than the “can’t get logs” toast?

1 Like

Thanks for the update!

The automation extracts a bunch of information and matches different parts and materials. Between versions the changes are often very minor and most of the matching can be adopted from previous versions making it more performant and consistent.

At the moment I am just ignoring the automation id and take the latest successful automation run from the previous version. This works for now since we only have a single automation running but might be troublesome in the future.

About the logging issue: I am suspecting some sort of rate limit or caching issue. Currently I am able to retrieve logs again. If I happen to run into it again I will try to aquire a few more logs and diagnosable symptoms.

Thanks!

1 Like

Excellent, that’s exactly what I’d recommend wrt automation runs. And understood on logs.

Tracking both issues, will keep you updated.