How to debug using cloud trace?

[tepid haven]

I am using dagger after a few weeks' break and I encountered the following error:

✘ Service.up: Void 2.9s
! failed to start host service: start upstream: start dependent services: start 75sppapgp3d5m

Error: response from query: input: container.from.withNewFile.withNewFile.withNewFile.withServiceBinding.withExposedPort.withNewFile.withServiceBinding.withExposedPort.withNewFile.withServiceBinding.withExposedPort.withExec.asService.up resolve: failed to start host service: start upstream: start dependent services: start 75sppapgp3d5m (aliased as monolith): exited: exit code: 1

Trace: https://dagger.cloud/esafak/traces/261dade85f2982349b577ce3a79815b5

[quartz nexus]

@tepid haven did you also update Dagger by any chance?

[tepid haven]

The CLI, yes, to 0.13.5. Do I need to do it in a particular way not to break the scripts?

[quartz nexus]

any chance you could be tripped by 0.13's useEntrypoint breaking change?
https://github.com/dagger/dagger/releases/tag/v0.13.0?

seems like your monolith service is not being able to start

if you have a function that returns that service, what I generally do is dagger call monolith up and check why the service failed to start

also try adding -vvv as that might output some more relevant information

could this be the error? https://dagger.cloud/esafak/traces/261dade85f2982349b577ce3a79815b5?span=69d0db8aa4373cd4

silently pinging @past cipher to double check if this error tracking is handled in the upcoming trace UI version

where when a service fails, it's hard to pin-point which exec failed exactly

[tepid haven]

I was about to say that. The debugging UX could be improved.

[quartz nexus]

agreed. This is a known limitation that it's in our backlog to address

[tepid haven]

The problem is that the user naturally digs in to the failed, 'red' events, but that's not where the error was, unless I'm using the product incorrectly. How did you zero in on it?

[quartz nexus]

The error message mentioned the monolith service failing to start, so I looked into the trace where the exec of that service was

[tepid haven]

It refers to start 75sppapgp3d5m (aliased as monolith) but I do not know how to find it. Is there a search feature?

[quartz nexus]

I looked for the monolith service here: https://dagger.cloud/esafak/traces/261dade85f2982349b577ce3a79815b5?span=6ba0521d07de737d

and then clicked in the asService span in the image attached which took me to the right exec operation

[tepid haven]

I'm trying to understand the color coding. Is this entry's expansion icon (top left in your screenshot) colored red to indicate a failure? Yet, the monolith withService has a green checkmark.

The UI is giving me unclear signals.

[quartz nexus]

yes, the UI is not surfacing the error correctly. I found the error because I started to trace back what happened with the monolith service since that was the only hint I've got from the error message. What we're working to fix is that the proper span (initial link that I've sent you) should be the one highlighted in red

[tepid haven]

How to debug using cloud trace?

[past cipher]

yeah the UI is not great around services right now - there are improvements ready to ship, I'll make sure to check on this specific case too where the service fails to start. Is the repo for this public by any chance so I can try running it and confirm the UX is solid?

[past cipher]

this confusing color mismatch will be gone too with the new UI (no more weird huge header with its own status icon)

[tepid haven]

It is private.