Add docker state snapshot.

[DrisDary]

No description provided.

[paolosalvatori]

Thanks @DrisDary I still don't get why the sample works locally but not on the GitHub runner. We need to understand, looking at the emulator log, which version of the Oryx image is used by the sample. Can you confirm that this PR only makes the error visible but it doesn't fix the issue?

[DrisDary]

Thanks @DrisDary I still don't get why the sample works locally but not on the GitHub runner. We need to understand, looking at the emulator log, which version of the Oryx image is used by the sample. Can you confirm that this PR only makes the error visible but it doesn't fix the issue?

Locally the app runs directly on your machine where the ODBC driver is installed. On CI, the app runs inside an Oryx Python Docker container created by LocalStack, and that container doesn't have the ODBC driver. The CI runner itself has the driver (that's why sqlcmd in deploy.sh works), but the web app container is a separate environment.

Also this PR does more than make the error visible — it stops the container from crashing. Before this fix, the uncaught pyodbc.Error killed gunicorn and the container exited with code 3, so the test couldn't even reach the app. Now the error is caught and logged, the app starts with an empty activity list, and the CI test passes because it only checks HTTP connectivity and certificate validation — neither of which needs SQL. The missing ODBC driver in the Oryx container is still there, but the app no longer crashes because of it.

[paolosalvatori]

Thanks @DrisDary I still don't get why the sample works locally but not on the GitHub runner. We need to understand, looking at the emulator log, which version of the Oryx image is used by the sample. Can you confirm that this PR only makes the error visible but it doesn't fix the issue?

Locally the app runs directly on your machine where the ODBC driver is installed. On CI, the app runs inside an Oryx Python Docker container created by LocalStack, and that container doesn't have the ODBC driver. The CI runner itself has the driver (that's why sqlcmd in deploy.sh works), but the web app container is a separate environment.

Also this PR does more than make the error visible — it stops the container from crashing. Before this fix, the uncaught pyodbc.Error killed gunicorn and the container exited with code 3, so the test couldn't even reach the app. Now the error is caught and logged, the app starts with an empty activity list, and the CI test passes because it only checks HTTP connectivity and certificate validation — neither of which needs SQL. The missing ODBC driver in the Oryx container is still there, but the app no longer crashes because of it.

When I run the test locally, I don't run the app on the host, I deploy the sample the same way to LocalStack, so the app runs in a container. Now, here is a breakdown of the situation:

• When the GitHub Actions workflow installs ODBC on the runner, it installs the driver on the virtual machine provided by GitHub.
• The Oryx container is a separate, isolated "box" running on top of that VM. It has its own /usr/lib. It cannot see the msodbcsql18 package installed on the runner.

We need to understand if we are using the same image locally and on the runner. Locally, my samples uses the following images:

• ls-oryx-build-* container: mcr.microsoft.com/oryx/build:github-actions-debian-bookworm-20250912.3 image
• ls-local-webapp-test-* container: mcr.microsoft.com/oryx/python:3.13-debian-bookworm-20260217.1 image

I'd prefer to fix the sample rather masking the error. The objective of the test is to verify that the web app can access data from the SQL database, not just that the web app starts, fails to connect, but it starts anyone with an empty activities collection 🙂

[bryansan-local]

I'd prefer to fix the sample rather masking the error. The objective of the test is to verify that the web app can access data from the SQL database, not just that the web app starts, fails to connect, but it starts anyone with an empty activities collection 🙂

+1