[madolson]

The module API reference links to /topics/protocol#attribute-type, but protocol.md has never documented the RESP3 attribute type (|), so that anchor doesn't exist. It is the one remaining failure in valkey-io/valkey-io.github.io#694's internal-links check. The link is generated from src/module.c at 9.1.0, so it can't be fixed in modules-api-ref.md. This adds an Attributes section with that anchor, and a row in the type table, based on what Valkey sends on RESP3 and RESP2 connections.

AI generated details

Problem

topics/modules-api-ref.md:1641 links to https://valkey.io/topics/protocol#attribute-type. The link came from valkey-io/valkey#433 (472c1ca26, first in 8.0.0), which pointed the VM_ReplyWithAttribute comment at valkey.io instead of antirez/RESP3/blob/master/spec.md#attribute-type. protocol.md never had that anchor, and git log -S'ttribute' -- topics/protocol.md is empty.

modules-api-ref.md is regenerated from src/module.c at VERSION ?= 9.1.0, and check-modules-api-ref.yml fails on hand edits. valkey-io/valkey#4845 drops the anchor from module.c on unstable, so the link goes away at the next release. The type stays undocumented either way.

Alternative considered

A bare <a name="attribute-type"></a> on an existing section fixes the check, but it sends readers to a page that doesn't describe the type. Documenting the type costs one short section.

What the section is based on

Line numbers are at the 9.1.0 tag. The attribute code is the same on unstable.

Claim	Source
|<count>\r\n then count key/value pairs, encoded like a map	addReplyAttributeLen, networking.c:1415-1417. Valkey parses it as len entries of 2 elements, call_reply.c:220
The reply follows the attribute and isn't one of its entries	debug.c:854. callReplyAttribute parses the attribute, then the reply, and attaches the attribute to it, call_reply.c:213-230
An attribute can precede an element inside an aggregate, and isn't counted in it	Aggregate elements go through the same parseReply dispatch, call_reply.c:201. EXEC produces one (see Testing)
RESP2: DEBUG PROTOCOL attrib sends only the bulk string	debug.c:847
RESP2: ValkeyModule_ReplyWithAttribute returns VALKEYMODULE_ERR	module.c:3400. Blocked-client and thread-safe contexts copy the real client's resp, module.c (unstable) 8571 and 9409

The anchor uses <a name>, like push-event, nil-reply and big-number-reply on the same page. lychee 0.24.2, which #694 uses, accepts name= anchors. In a two-page test site, #attribute-type passed against <a name="attribute-type"> in both relative and https://valkey.io/ form, and only a missing anchor was flagged.

Testing

Raw replies from valkey-server at valkey-io/valkey 7db2df1f7, captured with nc, with each line's \r\n made visible:

== DEBUG PROTOCOL attrib, RESP3 (after HELLO 3's map reply)
|1\r\n
$14\r\n
key-popularity\r\n
*2\r\n
$7\r\n
key:123\r\n
:90\r\n
$39\r\n
Some real reply following the attribute\r\n

== DEBUG PROTOCOL attrib, RESP2 (no HELLO, and the same after HELLO 2)
$39\r\n
Some real reply following the attribute\r\n

== HELLO 3, MULTI, DEBUG PROTOCOL attrib, PING, EXEC (EXEC reply)
*2\r\n
|1\r\n
$14\r\n
key-popularity\r\n
*2\r\n
$7\r\n
key:123\r\n
:90\r\n
$39\r\n
Some real reply following the attribute\r\n
+PONG\r\n

The site was built at valkey-io/valkey-io.github.io#694 head 9254bbac with the same content layout as its build-site action, and then checked with its build/broken-links.sh. Without this change:

$ website/build/compare-link-failures.sh - broken-before.tsv
Broken links (1):
::error::/topics/modules-api-ref/ links to /topics/protocol#attribute-type, but that page has no #attribute-type anchor

With it:

$ website/build/compare-link-failures.sh - broken-after.tsv
No broken links.

The site was built with Zola 0.21.0. #694's build-site action uses zola-deploy-action@v0.22.0. The `\|` table cell renders as <code>|</code>.

This was generated by AI but verified, with love, by a human.

[zuiderkwast]

Yes.

We may be able to use attributes for client opt-in stuff like compression.