// ToolUp Days #13

Coming off a session where the World Events Engine was “deployed but not quite working,” Chris and Matt open this episode by pulling up the Azure Container Apps logs and working methodically through the failure chain. What follows is a live debugging session that touches container image authentication, GitHub Actions permission models, Dapr component configuration, and storage queue message formatting.

Tracing the container startup failure

Container image pull failure — logs show the engine container failing with an image pull error against the GitHub Container Registry. Comparing the IaC for the working Player State container app against the World Events Engine IaC reveals the root cause: a registry credentials block (loginServer, username, password) was never added when the World Events Engine IaC was created — a copy-paste omission that had gone unnoticed.

GitHub Actions token permissions — with the image pull issue identified, the team audits whether the GITHUB_TOKEN has packages: write access. Chris walks through GitHub’s default permission model (read vs. read-and-write), organisation-level permission overrides, and the OIDC federated credential setup used for Azure login — highlighting how the id-token: write permission is distinct from package access, and why the two are easy to conflate.

Dapr naming conventions

A wider discussion surfaces inconsistencies in how services, state stores, and bindings are named across the project — singular vs. plural, with and without the -api suffix. A draft pull request with a naming glossary is on the backlog. The team notes that Dapr’s own community hasn’t fully converged on a naming convention yet, so pragmatism wins for now.

Storage queue message format

Initial tests dropping a plain-text message onto the Azure Storage Queue return HTTP 400 from the World Events Engine. Switching to a JSON-formatted payload ({ "tickId": "<guid>" }) resolves the issue and the endpoint starts receiving requests — confirming that the Dapr storage-queue binding expects a JSON body.

Multi-service local debugging

To step through the World Events Engine calling the Player State API, both services need to run simultaneously with their Dapr sidecars. Chris investigates three approaches:

• VS Code compound launch — run multiple launch configurations with one command
• PowerShell startup script — start all Dapr processes in parallel, managing port assignments manually
• Project Tye — a .NET orchestration tool with built-in Dapr support and a YAML manifest; promising but requires additional tooling

The team hits configuration issues with the VS Code approach (Dapr extension not found after switching from WSL to native Windows), prompting them to add console logging to the World Events Engine as a short-term diagnostic measure and to confirm that setting up a GitHub Codespaces environment is the right next step.

The episode closes with the storage queue message being consumed, an HTTP POST reaching the World Events Engine, and Dapr service invocation to Player State still to be verified — with a Codespaces episode confirmed for next time.