vitessio/vitess · error
ParseBinlogCoordinates: invalid pos: %s
Error message
ParseBinlogCoordinates: invalid pos: %s
What it means
The position part of a 'file:pos' string could not be parsed as an unsigned 64-bit integer by strconv.ParseUint. The file name portion was fine, but the text after the first colon is not a valid decimal integer (or is empty).
Source
Thrown at go/vt/vtorc/inst/binlog.go:57
// BinlogCoordinates described binary log coordinates in the form of log file & log position.
type BinlogCoordinates struct {
LogFile string
LogPos uint64
Type BinlogType
}
// ParseBinlogCoordinates will parse a string representation such as "mysql-bin.000001:12345"
// into a BinlogCoordinates struct.
func ParseBinlogCoordinates(logFileLogPos string) (*BinlogCoordinates, error) {
tokens := strings.SplitN(logFileLogPos, ":", 2)
if len(tokens) != 2 {
return nil, fmt.Errorf("ParseBinlogCoordinates: Cannot parse BinlogCoordinates from %s. Expected format is file:pos", logFileLogPos)
}
logPos, err := strconv.ParseUint(tokens[1], 10, 64)
if err != nil {
return nil, fmt.Errorf("ParseBinlogCoordinates: invalid pos: %s", tokens[1])
}
return &BinlogCoordinates{LogFile: tokens[0], LogPos: logPos}, nil
}
// DisplayString returns a user-friendly string representation of these coordinates
func (binlogCoordinates *BinlogCoordinates) DisplayString() string {
return fmt.Sprintf("%s:%d", binlogCoordinates.LogFile, binlogCoordinates.LogPos)
}
// String returns a user-friendly string representation of these coordinates
func (binlogCoordinates BinlogCoordinates) String() string {
return binlogCoordinates.DisplayString()
}
// Equals tests equality of this coordinate and another one.
func (binlogCoordinates *BinlogCoordinates) Equals(other *BinlogCoordinates) bool {
if other == nil {
return falseView on GitHub (pinned to 01a25a7d17)
Solutions
- Trim whitespace (strings.TrimSpace) from the coordinates string before parsing
- Verify the position field is a plain decimal integer: 'mysql-bin.000001:4711'
- Check the source of the string for CRLF line endings or appended units
- Confirm you split on the LAST colon if the binlog file path itself contains colons
Example fix
// before
coords, err := inst.ParseBinlogCoordinates("mysql-bin.000001: 4711\n")
// after
coords, err := inst.ParseBinlogCoordinates(strings.TrimSpace("mysql-bin.000001:4711")) Defensive patterns
Strategy: validation
Validate before calling
func validBinlogPos(s string) bool {
parts := strings.SplitN(s, ":", 2)
if len(parts) != 2 {
return false
}
_, err := strconv.ParseUint(strings.TrimSpace(parts[1]), 10, 64)
return err == nil
} Try / catch
raw = strings.TrimSpace(raw)
if !validBinlogPos(raw) {
return fmt.Errorf("invalid position in %q", raw)
}
coords, err := inst.ParseBinlogCoordinates(raw) Prevention
- strings.TrimSpace any value sourced from logs or shell output
- Strip CR characters from Windows-generated files
- Validate positions with ParseUint before calling library parsers
- Use structured SHOW status parsing instead of text scraping where possible
When it happens
Trigger: ParseBinlogCoordinates receiving inputs like 'mysql-bin.000001:abc', 'mysql-bin.000001:', or a position containing whitespace/newline from shell output or a mis-split log line.
Common situations: Scraping replication status from shell scripts that leave trailing whitespace or CR (Windows line endings), copying coordinates with extra characters, or a log file name containing a colon followed by non-numeric text.
Related errors
- ParseBinlogCoordinates: Cannot parse BinlogCoordinates from
- GetPreviousGTIDs: previous GTIDs not found
- Log file number is zero, cannot detect previous file
- no primary tablet found
- startPos.GTIDSet is wrong type - expected filePosGTID, got:
AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01).
Data as JSON: /api/errors/16965bfd2d9a0944.
Report an issue: GitHub.