hashicorp/terraform · error
getting lock info got an error: %#v
Error message
getting lock info got an error: %#v
What it means
Thrown as a secondary error (joined via errors.Join) while handling a failed PutRow in RemoteClient.Lock: after the lock write failed, the backend tried to best-effort fetch the existing lock info via getLockInfo, and that lookup also failed. The user gets both the PutRow failure and the lock-info retrieval failure.
Solutions
- Treat the primary PutRow error as the root cause; resolving OTS reachability/permissions resolves both.
- Verify credentials have both ots:PutRow and ots:GetRow on the table.
- Check OTS endpoint health and security-group/NAT egress.
- Retry once OTS is healthy; if a stale lock is suspected, manually inspect the table.
Defensive patterns
Strategy: try-catch
Try / catch
// When PutRow fails, attempt getLockInfo but tolerate its failure and report both errors.
_, err := c.otsClient.PutRow(putReq)
if err != nil {
putErr := fmt.Errorf("invoking PutRow got an error: %#v", err)
info, infoErr := c.getLockInfo()
if infoErr != nil {
err = errors.Join(putErr, fmt.Errorf("\ngetting lock info got an error: %#v", infoErr))
} else { err = putErr }
return "", &statemgr.LockError{Err: err, Info: info}
} Prevention
- Provision OTS permissions (PutRow + GetRow) as a unit so the secondary lookup rarely fails.
- Monitor OTS endpoint health; this double-error usually signals total OTS trouble.
- When this chained error appears, resolve OTS reachability first, then re-attempt the lock.
When it happens
Trigger: PutRow failed AND getLockInfo failed in sequence — e.g., OTS endpoint went fully unreachable mid-call, credentials lack both PutRow and GetRow, or the table was deleted between the two calls.
Common situations: Total OTS outage or permission failure affecting both write and read of the lock table; the lock row exists but GetRow is denied; network partition from runner to OTS.
Related errors
- failed to lock OSS state
- invoking PutRow got an error: %#v
- Error unlocking Alibaba Cloud OSS state file: Lock ID
- failed to retrieve lock info
- error describing table store
AI-assisted analysis of hashicorp/terraform@d32a084675 (2026-08-11).
Data as JSON: /api/errors/01f20e2a479f36fe.
Report an issue: GitHub.
Appendix: source
Thrown at internal/backend/remote-state/oss/client.go:198
ColumnName: "Info",
Value: string(info.Marshal()),
},
},
Condition: &tablestore.RowCondition{
RowExistenceExpectation: tablestore.RowExistenceExpectation_EXPECT_NOT_EXIST,
},
}
log.Printf("[DEBUG] Recording state lock in tablestore: %#v; LOCKID:%s", putParams, c.lockPath())
_, err := c.otsClient.PutRow(&tablestore.PutRowRequest{
PutRowChange: putParams,
})
if err != nil {
err = fmt.Errorf("invoking PutRow got an error: %#v", err)
lockInfo, infoErr := c.getLockInfo()
if infoErr != nil {
err = errors.Join(err, fmt.Errorf("\ngetting lock info got an error: %#v", infoErr))
}
lockErr := &statemgr.LockError{
Err: err,
Info: lockInfo,
}
log.Printf("[ERROR] state lock error: %s", lockErr.Error())
return "", lockErr
}
return info.ID, nil
}
func (c *RemoteClient) getMD5() ([]byte, error) {
if c.otsTable == "" {
return nil, nil
}
getParams := &tablestore.SingleRowQueryCriteria{View on GitHub (pinned to d32a084675)