Passing --store has weird syntax/requirements and user-facing error is not informative
Metadata
Current evaluation
A copied zero-width space in the --store value caused the 400 response; clean input succeeds. Clearer API errors and store-aware output are separable UX enhancements.
Suggested action: close not a bug
Reason: The captured payload explicitly contains "store": "\u200bgltNg0wohVae8aY4", while the equivalent --store=gltNg0wohVae8aY4 command returns 201. Maintainer ~sergiusens also noted that the visually similar commands differ and asked whether the input was copied, confirming this was malformed input rather than faulty option parsing.
Evaluated by: mr-cal-bot
Impact:
30
Quick Win:
12
Complexity:
25
Confidence:
96
Actionability:
55
Issue body
Trying to register a snap on a brand store for which I am a publisher (I have obfuscated the store ID and snap names).
$ snap run snapcraft register --store gltNg0wohVae8aY4 --yes does-this-look-correct
Registering does-this-look-correct.
Registration failed.
Let's look at what the HTTP dialog shows (macaroon elided). First problem: this requires hacking snapcraft as there doesn't seem to be a switch to enable this verbose debugging (SNAPCRAFT_ENABLE_DEVELOPER_DEBUG=yes --debug don't do the trick).
$ cp /snap/snapcraft/current/bin/snapcraft /tmp/snapcraft
$ sed -i '5iimport http.client\nhttp.client.HTTPConnection.debuglevel = 1\n' /tmp/snapcraft
$ sudo mount -o bind /tmp/snapcraft /snap/snapcraft/current/bin/snapcraft
$ snap run snapcraft register --store gltNg0wohVae8aY4 --yes does-this-look-correct
Registering does-this-look-correct.
send: b'POST /dev/api/register-name/ HTTP/1.1\r\nHost: dashboard.snapcraft.io\r\nUser-Agent: snapcraft/4.3 Ubuntu/18.04 (amd64)\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nAuthorization: Macaroon root=<my root macaroon>, discharge=<my discharge>\r\nContent-Type: application/json\r\nContent-Length: 130\r\n\r\n'
send: b'{"snap_name": "does-this-look-correct", "is_private": false, "series": "16", "store": "\\u200bgltNg0wohVae8aY4"}'
reply: 'HTTP/1.1 400 Bad Request\r\n'
header: Date: Thu, 08 Oct 2020 13:13:31 GMT
header: Server: gunicorn/19.7.0
header: Content-Type: application/json
<boring headers>
header: Connection: close
header: Transfer-Encoding: chunked
Registration failed.
Second problem: Snapcraft's response on a 400 reply from the store is too terse to be useful.
OK, so looking at the post payload, the store name is borked:
"store": "\\u200bgltNg0wohVae8aY4"
Looks like snapcraft is not properly parsing the --store command-line parameter value. Let's try this:
$ snap run snapcraft register --store=gltNg0wohVae8aY4 --yes does-this-look-correct
Registering does-this-look-correct.
send: b'POST /dev/api/register-name/ HTTP/1.1\r\nHost: dashboard.snapcraft.io\r\nUser-Agent: snapcraft/4.3 Ubuntu/18.04 (amd64)\r\nAccept-Encoding: gzip, deflate\r\nAccept: */*\r\nConnection: keep-alive\r\nAuthorization: Macaroon root=<root>, discharge=<disch>\r\nContent-Type: application/json\r\nContent-Length: 124\r\n\r\n'
send: b'{"snap_name": "does-this-look-correct", "is_private": false, "series": "16", "store": "gltNg0wohVae8aY4"}'
reply: 'HTTP/1.1 201 Created\r\n'
header: Date: Thu, 08 Oct 2020 13:14:35 GMT
header: Content-Language: en
header: Content-Type: application/json
header: X-VCS-Revision: 8ee7d2f
< A bunch of boring headers elided>
Congrats! You are now the publisher of 'does-this-look-correct'.
This is the third issue. It's workaroundable by using --store=, we can use that in the meanwhile but it would be great if snapcraft would properly parse command-line options.
I realize in hindsight this is an omnibug. Let me know if you'd prefer I file all 3 issues separately, I can gladly do it.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
30
Quick Win:
12
Complexity:
25
Confidence:
96
Actionability:
55
|
close not a bug | A copied zero-width space in the --store value caused the 400 response; clean input succeeds. Clearer API errors and store-aware output are separable UX enhancements. | |
| stealth/space-bunny-alpha |
Impact:
40
Quick Win:
18
Complexity:
38
Confidence:
84
Actionability:
74
|
keep open | `register --store` sends a pasted invisible U+200B and gives a generic failure for store 400s; using `--store=<id>` works, and the issue remains open. | |
| qwen/qwen3.6-35b-a3b |
Impact:
5
Quick Win:
0
Complexity:
5
Confidence:
95
Actionability:
10
|
close not a bug | User reported --store parsing issues and poor error messages. Issue is 6 years old; root cause was copy-pasting a hidden Unicode character. Codebase has been refactored. | |
| qwen/qwen3.8-27b |
Impact:
20
Quick Win:
14
Staleness:
95
Complexity:
30
Confidence:
60
Support Request:
30
|
close stale | 2020 report that snapcraft register with --store failed with an uninformative 'Registration failed' error; the mangled store value in the payload matches a zero-width space in the reporter's own pasted command. No maintainer response in ~6 years; snapcraft 4.3 is long out of support. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
20
Confidence:
85
Support Request:
0
|
close stale | Bug report from 2020 regarding uninformative errors and CLI parsing issues when using --store with a space instead of =. Targets EOL snapcraft 4.3/Ubuntu 18.04. No updates in over 5 years. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
95
Complexity:
35
Confidence:
85
Support Request:
15
|
close stale | snapcraft register --store fails with uninformative errors when the store ID contains hidden characters. No maintainer response, inactive for over 5 years. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
95
Complexity:
15
Confidence:
85
Support Request:
10
|
close stale | Untriaged report from 2020 regarding snapcraft CLI argument parsing and unhelpful error messages during snap registration. The issue remains completely inactive with zero maintainer engagement or labels. |
Update history
| Date | Change |
|---|---|
| created |
Related issues
No related issues found above the similarity threshold.