What causes "no attribute view rows selected" in siyuan-note/siyuan?

Ensure the drag payload includes at least one selected row ID before calling the sort API

no attribute view rows selected

Error message

no attribute view rows selected

What it means

moveAttributeViewSortedRows builds a set of the selected row IDs and rejects the operation when that set is empty. An empty selection means there is nothing to move, so the row-sort drag operation is aborted with this error.

Source

Thrown at kernel/model/attribute_view_row_sort.go:172

	}
	return ret, nil
}

func attributeViewRowSortIDs(items []av.Item) []string {
	ret := make([]string, 0, len(items))
	for _, item := range items {
		ret = append(ret, item.GetID())
	}
	return ret
}

func moveAttributeViewSortedRows(ordered, selected []string, previousID, nextID string) ([]string, error) {
	selectedIDs := map[string]bool{}
	for _, id := range selected {
		selectedIDs[id] = true
	}
	if 0 == len(selectedIDs) {
		return nil, errors.New("no attribute view rows selected")
	}
	var moved, remaining []string
	for _, id := range ordered {
		if selectedIDs[id] {
			moved = append(moved, id)
		} else {
			remaining = append(remaining, id)
		}
	}
	if len(moved) != len(selectedIDs) {
		return nil, errors.New("attribute view rows changed; retry the drag")
	}
	if selectedIDs[nextID] || ("" == nextID && selectedIDs[previousID]) {
		return slices.Clone(ordered), nil
	}
	index := 0
	if "" != nextID {
		index = slices.Index(remaining, nextID)

View on GitHub (pinned to 8641553a1f)

Solutions

Ensure the drag payload includes at least one selected row ID before calling the sort API
Re-fetch the current selection from the frontend state and retry the operation
Discard the stale drag operation and have the user re-perform the drag

Example fix

// before
rows, err := moveAttributeViewSortedRows(ordered, selected, prevID, nextID)
// after
if len(selected) == 0 {
    return nil // nothing to move; skip the sort request
}
rows, err := moveAttributeViewSortedRows(ordered, selected, prevID, nextID)

Defensive patterns

Strategy: validation

Validate before calling

if (!selected || selected.length === 0) {
    return; // nothing to move, skip the sort API call
}

Prevention

Only invoke row-sort when at least one row is selected
Clear drag state when the selection changes
Guard programmatic API calls with a non-empty selection check

When it happens

Trigger: Calling prepareAttributeViewRowSort (which delegates to moveAttributeViewSortedRows) with an empty `selected` slice — e.g. the frontend submitted a row drag payload with no row IDs, or the selection was cleared between drag start and commit.

Common situations: Frontend drag handlers sending stale/empty selection arrays; a script or plugin invoking the row sort API programmatically with an empty selected list; rows deleted concurrently so the selected-ID array arrived empty.

Understand the failure class

Background: "must not be empty", "cannot be empty" — required-field validation errors across open-source libraries — this error's family across 41 libraries.

Related errors

AI-assisted analysis of siyuan-note/siyuan@8641553a1f (2026-09-11). Data as JSON: /api/errors/d5e379d7bcf27b29. Report an issue: GitHub.