What causes "resolving last data row for append: %w" in larksuite/cli?

Retry the put; lastDataRow failures are often transient network or rate-limit issues.

resolving last data row for append: %w

Error message

resolving last data row for append: %w

What it means

During a sheet table put in append mode, writeSheetData must first resolve the current last data row of the target sheet to know where to anchor the appended rows. This error wraps any failure of lastDataRow (reading sheet dims/values) so the append cannot proceed. It is surfaced as a partial_success message string via tablePutPartial, not a typed final error.

Source

Thrown at shortcuts/sheets/lark_sheet_table_io.go:867

// writeSheetData writes one sheet's matrix via set_cell_range, splitting into
// row batches when the cell count would exceed tablePutMaxCellsPerWrite.
// Returns a per-sheet summary for the result envelope.
func writeSheetData(ctx context.Context, runtime *common.RuntimeContext, token, sheetID string, s *tableSheetSpec, styles *workbookCreateStylePayload, dims gridDims) (map[string]interface{}, error) {
	_, col0, row0, err := sheetAnchor(s)
	if err != nil {
		return nil, err
	}
	ncols := len(s.Columns)

	// append mode starts below the sheet's existing data; start_cell's row is
	// ignored (its column is still honored). overwrite mode anchors at row0.
	baseRow := row0
	writeHeader := headerOn(s)
	if s.Mode == "append" {
		lastRow, err := lastDataRow(ctx, runtime, token, sheetID, dims)
		if err != nil {
			return nil, fmt.Errorf("resolving last data row for append: %w", err) //nolint:forbidigo // intermediate error; surfaced as a partial_success message string via tablePutPartial, not a typed final error
		}
		if lastRow > 0 {
			baseRow = lastRow // 0-based index of the row just below the 1-based last data row
		} else if s.Header == nil {
			// appending to an empty sheet with no explicit header choice: write the
			// header so column names aren't lost (and a later +table-get doesn't
			// consume the first data row as the header).
			writeHeader = true
		}
	}

	matrix, err := buildSheetMatrix(s, writeHeader)
	if err != nil {
		return nil, err
	}
	matrix, err = applyWorkbookCreateStylesToMatrix(matrix, styles, col0, baseRow, fmt.Sprintf("--styles for sheet %q", s.Name))
	if err != nil {
		return nil, err

View on GitHub (pinned to 7fd6ef3c07)

Solutions

Retry the put; lastDataRow failures are often transient network or rate-limit issues.
Verify the spreadsheet token and sheet ID/name resolve with a read command (e.g. table get).
Check the token has spreadsheet read+write scopes for the target sheet.
Confirm the sheet still exists and wasn't removed by a concurrent edit.

Example fix

// before (ambiguous name, read fails)
lark sheet table put --token 123 --sheet "Sumary" --mode append --header A,B --row 1,2
// after (verify exact sheet name exists first)
lark sheet table get --token 123 --sheet "Summary"   # confirm readable, then append

Defensive patterns

Strategy: retry

Validate before calling

// verify the target is readable before appending:
_, err := runCLI("lark", "sheet", "table", "get", "--token", token, "--sheet", sheet)
if err != nil { /* resolve access before attempting append */ }

Try / catch

if strings.Contains(err.Error(), "resolving last data row for append") {
	// inspect partial_success message; backoff and retry the append
}

Prevention

Pre-read the sheet with table get to confirm access and existence.
Use tokens with both read and write spreadsheet scopes.
Retry appends with exponential backoff on transient failures.

When it happens

Trigger: Running lark sheet table put with mode=append when the API call that reads the sheet's dimensions or existing values fails (network error, permission error, or sheet/token not found) inside lastDataRow.

Common situations: Expired or insufficient token scopes for reading the sheet; a spreadsheet_token typo; the sheet was deleted between listing and writing; transient network failures against the Lark gateway.

Related errors

AI-assisted analysis of larksuite/cli@7fd6ef3c07 (2026-09-04). Data as JSON: /api/errors/16ad37e0f9249569. Report an issue: GitHub.