Clovis
12/18/2023, 11:10 AMImportError: cannot import name 'secretmanager' from 'google.cloud' (unknown location)
The docker image I’m using to run the job is the obviously the same for both manual and auto-scheduled runs and it does correctly install the google-cloud-secret-manager
package (which is proven by the way it works when running it manually), so I don’t understand why the behavior is not the same between those 2 runs.
Can you explain why it reacts differently ?Marvin
12/18/2023, 11:11 AMImportError: cannot import name 'secretmanager' from 'google.cloud'
and the fact that this issue arises only during auto-scheduled runs and not manual runs using the same Docker image, I can suggest a few potential causes and solutions to look into:
1. Environment Discrepancy: Make sure that the environment for scheduled runs is identical to the one used for manual runs. Differences in environment variables, service accounts, or Cloud Run configurations might lead to different behavior in resolving packages or access permissions.
2. Dependency Cache: Sometimes, Docker images might be cached with older layers that didn't have the correct dependencies installed. Try to force rebuild the Docker image, even though the issue doesn't appear in manual runs, to ensure there isn't a cached layer causing the problem.
3. Timing Issue: There could be a race condition where the auto-scheduled run is attempting to import secretmanager
before the google-cloud-secret-manager
package is fully available. This is less likely if you are not dynamically installing packages during startup, but it's something to consider.
4. Access Permissions: Auto-scheduled runs might have different IAM roles or permissions compared to manual runs. Confirm that the service account used by the Cloud Run executor has the correct permissions to access Secret Manager.
5. **Dependency
Conflicts**: Another possibility is that there are conflicting packages or versions being installed that interfere with the availability of the secretmanager
module. Verify that there are no version conflicts in your installed packages between your local development environment and the environment where the Docker image is being built.
6. Code Execution Path: It's also possible that the code path during the auto-scheduled run differs from the manual run, leading to an import statement being executed in one scenario but not the other. Double-check the flow logic to ensure consistency.
7. Package Initialization: Verify that the initialization of the google-cloud-secret-manager
package does not require any special environment setup that could differ between scheduled and manual runs.
If none of these suggestions resolve the issue, it may be helpful to add additional logging to your flow or Docker image build process to capture more details about the environment and package installation during the auto-scheduled runs. This can help you pinpoint discrepancies or issues in the environment or execution context that could be causing the import error.
Since there's no existing issue on the Prefect GitHub repository about this specific problem, if you're unable to resolve the error after these checks, consider reaching out to Prefect's support channels or filing a new issue to get further assistance.