dnsimple / dnsimple/cli

The records update command does not set a priority of 0

Open
#67 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Go
Stars
3
Forks
0
Avg merge
8h 39m
Merged PRs (30d)
9

Description

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

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the records update command entry point and trace how the --priority value is converted into the API request body. Reproduce both --priority 0 and --priority=0, then verify the request, table output, and JSON output; done means both forms send and display priority 0 without requiring record recreation.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
api, cli
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.