siyuan-note/siyuan · error

unsupported attribute view key type [%s]

Error message

unsupported attribute view key type [%s]

What it means

Thrown by AddAttributeViewKey's default switch case when operation.Typ (keyType) is not one of the recognized KeyType values (block, text, number, date, select, mSelect, url, email, phone, mAsset, template, created, updated, checkbox, relation, rollup, lineNumber). Unknown types are rejected so that no half-defined column is persisted.

Source

Thrown at kernel/model/attribute_view.go:7046

				if "" == previousKeyID {
					view.Kanban.Fields = append(view.Kanban.Fields, &av.ViewKanbanField{BaseField: newField})
				} else {
					added := false
					for i, field := range view.Kanban.Fields {
						if field.ID == previousKeyID {
							view.Kanban.Fields = append(view.Kanban.Fields[:i+1], append([]*av.ViewKanbanField{{BaseField: newField}}, view.Kanban.Fields[i+1:]...)...)
							added = true
							break
						}
					}
					if !added {
						view.Kanban.Fields = append(view.Kanban.Fields, &av.ViewKanbanField{BaseField: newField})
					}
				}
			}
		}
	default:
		return fmt.Errorf("unsupported attribute view key type [%s]", keyType)
	}

	err = av.SaveAttributeView(attrView)
	return
}

func (tx *Transaction) doUpdateAttrViewColTemplate(operation *Operation) (ret *TxErr) {
	err := updateAttributeViewColTemplate(operation)
	if err != nil {
		return &TxErr{code: TxErrHandleAttributeView, id: operation.AvID, msg: err.Error()}
	}
	return
}

func updateAttributeViewColTemplate(operation *Operation) (err error) {
	attrView, err := av.ParseAttributeView(operation.AvID)
	if err != nil {
		return

View on GitHub (pinned to 251596fc0d)

Solutions

1. Send only KeyType values the running kernel enumerates; maintain a client-side whitelist synchronized with the kernel.
2. Upgrade the kernel (or downgrade the client) so the type vocabulary matches.
3. Double-check spelling/casing of the type string against av.KeyType constants.

Example fix

// before
AddAttributeViewKey(avID, blockID, keyID, name, 'multi-select', ...) // wrong token
// after
AddAttributeViewKey(avID, blockID, keyID, name, 'mSelect', ...) // correct KeyType

const KNOWN_KEY_TYPES = ['block','text','number','date','select','mSelect','url','email','phone','mAsset','template','created','updated','checkbox','relation','rollup','lineNumber']
if (!KNOWN_KEY_TYPES.includes(op.type)) { /* reject before sending */ }

type KeyType = 'block'|'text'|'number'|'date'|'select'|'mSelect'|'url'|'email'|'phone'|'mAsset'|'template'|'created'|'updated'|'checkbox'|'relation'|'rollup'|'lineNumber'
function isKeyType(s: string): s is KeyType { return ['block','text','number','date','select','mSelect','url','email','phone','mAsset','template','created','updated','checkbox','relation','rollup','lineNumber'].includes(s) }

When it happens

Trigger: A typo in the keyType string (e.g. 'select-multi' instead of 'mSelect'); a future/legacy keyType the running kernel does not recognize; a plugin sending a custom type the kernel never enumerates.

Common situations: Version mismatch between frontend and kernel (newer frontend sending a type the older kernel lacks); copy-paste errors in scripts building add-column operations; a plugin extending the type vocabulary without kernel support.

Related errors

• cannot add an attribute view block key
• invalid date display format
• invalid attribute view id
• invalid box id
• wrong layout type

AI-assisted analysis of siyuan-note/siyuan@251596fc0d (2026-08-12). Data as JSON: /api/errors/ba42644eb99ffd80. Report an issue: GitHub.