Skip to content

Conversation

@tonistiigi
Copy link
Member

Fixes cache export error handling for the case where a blob that is part of the imported cache, but doesn't actually participate in the current build has been removed in the cache source, and fails when in it transferred to new cache on export.

Two commits. Technically, either of them solves the issue of the build failing. First commit doesn't drop any cache metadata but is specific to the error caused by the blob being removed. The second one works on any export error in the cache chain, but causes the branch that the error affects to be dropped (that may cause the parents to be dropped if there are no valid input combinations left).

This is a regression in v0.25 from cache refactor. The reason it worked before is this nil return https://github.com/moby/buildkit/blob/v0.24.0/solver/exporter.go#L201 from subchain export error. Note that there was no similar return for "subexporters". There is also "exist" check in marshalRemote in both versions, but in this specific case it is not reached. While v0.24 there was no error, when this case was hit the return nil likely corrupted the exported cache chains (at least that is what happens in my reproducer). This PR seems to work correctly, blob is skipped but the rest of the updated cache is still perfectly valid.

Don't fail whole cache export on subbranch error.

This behavior changed in v0.25, but while before
error was not returned, the cache chains were either
too agressively dropped or the whole exported
cache chain got corrupted.

Signed-off-by: Tonis Tiigi <[email protected]>
if err != nil {
return nil, err
}
res.Release(context.TODO())
Copy link
Member

Choose a reason for hiding this comment

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

Looks like existing code, but there's a context available here; could this / should this be a context.WithoutCancel(ctx) ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, these could be updated. This is old code before WithoutCancel was a thing.

Comment on lines 239 to +240
if err != nil {
return nil, err
continue
Copy link
Member

Choose a reason for hiding this comment

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

Is there something to do with this error? (I see it's fully discarded); something to log, or collect in a multi-error (and have a single log or something)?

Copy link
Member Author

Choose a reason for hiding this comment

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

We could log them as warnings but v0.24 didn't log them as well, so as a regression fix I don't think this change is needed.

Comment on lines 251 to +252
if err != nil {
return nil, nil
continue
Copy link
Member

Choose a reason for hiding this comment

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

Same for this one

@tonistiigi tonistiigi merged commit c132bdf into moby:master Oct 3, 2025
140 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants