The records update command does not set a priority of 0

[weppos]

Description

The records update command does not set the priority of a zone record to 0. The command sends an empty JSON body ({}) to the API. The API returns HTTP 200, and the record keeps its previous priority. The command prints the unchanged record and does not print an error, so the user can believe that the update is successful. The value 0 is a valid MX priority, and some mail providers document a priority of 0 for their MX records.

This scenario uses the zone wonderland.test. The user creates an MX record with a priority of 10, and then tries to change the priority to 0.

$ dnsimple records create wonderland.test --type MX --name "" --content "mx1.mailhost.test" --priority 10 --ttl 3600
FIELD          VALUE
ID             10000001
Type           MX
Name
Content        mx1.mailhost.test
TTL            3600
Priority       10

$ dnsimple records update wonderland.test 10000001 --priority 0
FIELD          VALUE
ID             10000001
Type           MX
Name
Content        mx1.mailhost.test
TTL            3600
Priority       10

The command exits with code 0. The priority stays at 10. The --priority=0 form gives the same result. The --debug output shows that the request body has a length of 3 bytes, which is the empty JSON object.

$ dnsimple records update wonderland.test 10000001 --priority=0 --debug
2026/08/17 10:00:57 Request (https://api.dnsimple.com/v2/1234/zones/wonderland.test/records/10000001): &http.Request{Method:"PATCH", ... ContentLength:3, ...}
2026/08/17 10:00:57 Response: &http.Response{Status:"200 OK", ...}

The records create command accepts a priority of 0. The workaround is to delete the record and to create it again. This workaround changes the record ID, and it removes the mail route of the zone for a short time.

Expected Behavior or Outcome

• The records update command sets the priority to 0 when the user gives --priority 0.
• The command sends the priority field in the request body when the user gives the flag.
• The output shows the new priority of the record.
• The command does not report a successful result when it does not change the record.

Acceptance Criteria

• The command dnsimple records update <zone> <record-id> --priority 0 sets the priority of the record to 0.
• The request body contains the priority field when the user gives the --priority flag with a value of 0.
• The command gives the same result for the --priority 0 form and the --priority=0 form.
• The output of the command shows a priority of 0 after the update.
• The user does not need to delete and create the record again to set a priority of 0.

Resources/References

• DNSimple API, update a zone record: https://developer.dnsimple.com/v2/zones/records/#updateZoneRecord

Notes

The problem occurs with dnsimple version 0.10.0 on macOS (arm64).

The table output and the JSON output omit the priority field when the priority is 0. A record with a priority of 0 shows no priority line in the table, and the JSON data object has no priority key. This behavior makes it difficult to confirm the value of the priority.

Other numeric flags that accept 0 as a valid value can have the same problem. This issue reports only the --priority flag of the records update command.

[ggalmazor]

Thank you for the detailed report, and for capturing the --debug output. It made this one quick to pin down.

The records update command is not the origin of the defect. It already forwards the flag whenever the user sets it, because it guards on the flag having been changed rather than on its value:

if cmd.Flags().Changed("priority") {
	attrs.Priority = priority
}

The value is dropped one layer below, in dnsimple-go. ZoneRecordAttributes.Priority is a non-pointer int tagged omitempty, so a priority of 0 is indistinguishable from an unset priority at serialization time and is omitted from the payload:

type ZoneRecordAttributes struct {
	ZoneID   string   `json:"zone_id,omitempty"`
	Type     string   `json:"type,omitempty"`
	Name     *string  `json:"name,omitempty"`
	Content  string   `json:"content,omitempty"`
	TTL      int      `json:"ttl,omitempty"`
	Priority int      `json:"priority,omitempty"`
	Regions  []string `json:"regions,omitempty"`
}

That is why the request body is the 3-byte {} you captured, and why the API answers 200 OK without changing the record. Note that Name is already a *string for exactly this reason, as the type's own documentation explains. We have opened dnsimple/dnsimple-go#269 to track that fix.

The output behavior you describe in the Notes does belong to this repository. Both record printers suppress the row when the priority is 0:

if rec.Priority != 0 {
	rows = append(rows, []string{"Priority", strconv.Itoa(rec.Priority)})
}

This is internal/cli/zones_records.go:69 and internal/cli/templates_records.go:57. Therefore a record with a priority of 0 renders no priority line even once the update lands, which is what makes the value hard to confirm.

Keeping this ticket open for the output change and for the end-to-end Acceptance Criteria, which we can only close after dnsimple/dnsimple-go#269 ships and we bump the dependency here.

We should also revisit newRecordsCreateCmd, which guards on if priority > 0 rather than on cmd.Flags().Changed("priority"). It will need the same treatment once the serialization is fixed.