CaptainAni187 opened a new pull request, #2095: URL: https://github.com/apache/iceberg-go/pull/2095
Closes #2091. `buildCommonMetadata` appended the previous metadata file to `b.metadataLog` and trimmed it in place, so every `Build()` on a builder with changes added one more identical entry. It now extends and trims a copy, so `Build()` leaves the builder unchanged and returns the same log however many times it runs. This only affects metadata built from an in-flight transaction (`StagedTable()`, `Transaction.Scan`, and the builds inside a copy-on-write delete). As the issue notes, committed metadata was already correct, because catalogs rebuild it from the base and the updates. Tests: - `TestBuildDoesNotGrowMetadataLog`: three `Build()` calls on one builder each return a single previous-file entry. On main the second call returns two. - `TestBuildDoesNotTrimTheBuilderMetadataLog`: with `write.metadata.previous-versions-max=2` and the log at its limit, repeated builds keep `[v2, v3]`. On main the in-place trim turns the second build into `[v3, v3]`, which a length check alone would miss. - `TestCopyOnWriteDeleteStagesSinglePreviousMetadataLogEntry`: the reproduction from the issue. A copy-on-write delete that rewrites two files, then `StagedTable()`. On main it lists the same file 5 times; now it lists it once. `go test ./...` passes and `golangci-lint run` (v2.14.0) reports 0 issues. I left the separate idea from the issue, building once per operation rather than once per file on the copy-on-write path, out of this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
