Skip to content

Conversation

@WVerlaek
Copy link
Member

@WVerlaek WVerlaek commented Jan 7, 2026

Description

When a build fails, leeway was using log.Fatal to shutdown, but this doesn't run any defer-ed cleanup functions preventing otel from pushing all spans. Results in incomplete traces

The pr changes the build command to return errors instead of using log.Fatal, and then have one top-level log.Fatal (after otel shutdown has run).

Related Issue(s)

Relates to CORE-6452

How to test

Complete traces in honeycomb now:
image
https://ui.honeycomb.io/gitpod/environments/ci/datasets/leeway/result/e9NjDmof1Yh/trace/pct7KaVe6Z4?fields%5B%5D=s_name&fields%5B%5D=s_serviceName&span=96f4a3ca1c7caed8

Documentation

/hold

},
}

func build(cmd *cobra.Command, args []string) error {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

build() is the same logic as what was in the Run function above, except that log.Fatals have been replaced by returning an error.

RunE above still logs any errors with log.Fatal, so the leeway log output remains the same

@kylos101
Copy link
Contributor

kylos101 commented Jan 7, 2026

I related to CORE-6452 (moving the related issue to our new project).

Copy link
Contributor

@kylos101 kylos101 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👋 @WVerlaek , sorry about the delay! Looks good. Added some nits which are not blocking. Can be addressed in follow-up PRs if desired.

// Ensure cache directory exists with proper permissions
if err := os.MkdirAll(buildDir, 0755); err != nil {
log.WithError(err).Fatal("failed to create build directory")
return nil, xerrors.Errorf("failed to create build directory: %w", err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, not blocking:
func newBuildContext is used by leeway when running scripts, too. (ref)

Build was changed to RunE, but not Run.

We could do similar for running scripts (to be consistent). (ref).

However, if we don't, that's fine because it'll still handle the error and log.fatal.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would still result in a log.Fatal indeed when an error gets returned as part of the run command. There's a ton of log.Fatal left throughout the codebase, it would require a larger cleanup to change all

}
if serve != "" {
go serveBuildResult(ctx, serve, localCache, pkg)
return err
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, not blocking:
It looks like we could invoke cancel() before returning the error, to be tidy, not a functional problem.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

added

err = saveBuildResult(context.Background(), save, localCache, pkg)
if err != nil {
log.Fatal(err)
return err
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, not blocking:
We could wrap the error with with return fmt.Errorf("...: %w", err) to help future us catch where this happened.

The same is true with above errors. I wonder if maybe I am missing a convention?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

didn't want to change the output that leeway produces, assumption was that these errors already include enough details and wrapping them would make them more verbose

@WVerlaek WVerlaek merged commit 326bef4 into main Jan 8, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants