ChickenBenny opened a new pull request, #75551:
URL: https://github.com/apache/airflow/pull/75551
The Go SDK did not compile where `int` is 32 bits (`GOARCH=386`, `arm`,
`mipsle`), so `airflow-go-pack --goarch=arm` could not build a bundle for a
32-bit worker:
$ cd go-sdk && GOARCH=386 go build ./...
internal/bundlefooter/footer.go:87:4: cannot use MaxRegionSize (untyped
int constant 4294967295) as int value in argument to fmt.Errorf (overflows)
pkg/execution/frames.go:98:20: MaxFrameSize (untyped int constant
4294967295) overflows int
...
`MaxFrameSize` and `MaxRegionSize` are `2^32 - 1`, which does not fit in a
32-bit `int` when compared with `len()` or passed to `fmt.Errorf`.
`frames_oversized_test.go` already skips on a 32-bit `int`, so these targets
seem meant to work.
Once it compiled, `parseRetentionDays` also misbehaved on 32-bit: it checked
the value against the int64 range, so `default_retention_days = 3000000000`
wrapped and failed with `must be >= 0, got -2147483648`. It is now bounded by
the platform's `int`.
Tested locally with the project's Go 1.25:
- `go test ./...` and `go test -race ./...`
- `GOARCH=386 go test ./...`
- `go vet ./...` for 386, arm and mipsle
Nothing in CI builds for 32-bit, so this can break again. Would a
`GOARCH=386 go vet ./...` step in the Go SDK workflow be welcome here or as a
follow-up?
--
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]
